Quali sono le caratteristiche di esaurimento di RDRAND su Ivy Bridge?

Question

Dopo aver esaminato lo Intel Digital Random Number Generator (DRNG) Software Implementation Guide, ho alcune domande su cosa succede allo stato interno del generatore quando viene richiamato RDRAND. Sfortunatamente le risposte non sembrano essere nella guida.

1. Secondo la guida, all'interno della DRNG ci sono quattro buffer 128 bit che servono bit casuali per RDRAND di scarico. RDRAND stessa provvederà o 16, 32, o 64 bit di dati casuali secondo la larghezza del registro di destinazione:

   rdrand ax ; put 16 random bits in ax 
   rdrand eax ; put 32 random bits in eax 
   rdrand rax ; put 64 random bits in rax 
   

   Sarà l'uso di registri destinazione grandi svuotare i buffer a 128 bit più rapidamente? Ad esempio, se ho bisogno solo di 2 bit di casualità, dovrei passare attraverso il problema di usare un registro a 16 bit su un registro a 64 bit? Questo farà alcuna differenza sul throughput del DRNG? Mi piacerebbe evitare di consumare più casualità del necessario.

2. La guida dice verrà impostato il flag di carry dopo RDRAND esegue:

   CF = 1 Destination register valid. Non-zero random value 
        available at time of execution. Result placed in register. 
   CF = 0 Destination register all zeros. Random value not available 
        at time of execution. May be retried. 
   

   Che cosa significa "non disponibile" significa? I dati casuali non sono disponibili perché le chiamate RDRAND hanno esaurito troppo rapidamente i buffer a 128 bit? O non è disponibile significa che il DRNG sta fallendo i suoi controlli di integrità e non può generare nuovi dati? Fondamentalmente, sto cercando di capire se CF = 0 può verificarsi solo perché i buffer capita di essere (transitoriamente) vuoto quando viene invocato RDRAND.

Nota: Ho rivisto il answers a this question on throughput and latency of RDRAND, ma io sto cercando informazioni diverse.

Grazie!

Answer 1

Parte 1. Fa una differenza tirando 16, 32 o 64 bit?

No.

In Ivy Bridge, i nuclei CPU tirare 64 bit sui collegamenti di comunicazione interni alla DRNG, indipendentemente dalle dimensioni del registro di destinazione. Quindi se leggi 32 bit, tira 64 bit e butta via la metà superiore. Se leggi 16 bit, tira 64 e getta via il 3/4 in alto.

Questo non è descritto nella documentazione delle istruzioni perché potrebbe non continuare ad essere vero nei prodotti futuri. È possibile progettare un chip che memorizza e utilizza le parti non utilizzate della parola a 64 bit. Tuttavia non c'è un imperativo significativo delle prestazioni per farlo oggi.

Per il throughput più elevato, la strategia più efficace è quella di eseguire il pull da thread paralleli. Questo perché c'è un parallelismo nella gerarchia del bus su chip. Il più delle volte per le istruzioni è il tempo di transito attraverso gli autobus. Eseguendo quel transito in parallelo si otterrà un aumento lineare della velocità effettiva con il numero di thread, fino a un massimo di 800MBytes/s. La seconda cosa è usare gli RdRands a 64 bit, perché ottengono più dati per istruzione.

Parte 2. Cosa significa CF = 0 in realtà?

Significa "dati casuali non disponibili". Questo perché i dettagli del perché non è possibile ottenere un numero non sono disponibili per il core della CPU senza che si spenga e leggendo più registri, cosa che non succederà perché non c'è nulla che possa fare con le informazioni.

Se il buffer di output del DRNG è stato risucchiato, si otterrebbe un underflow (CF = 0) ma è possibile che il successivo RdRand abbia esito positivo, poiché il DRNG è veloce.

Se il DRNG non è riuscito (ad esempio un transistor è scoppiato nella fonte di entropia e non è più casuale), i test di integrità online potrebbero rilevare questo e arrestare il DRNG. Quindi tutte le invocazioni RdRand produrranno CF = 0.

Tuttavia su Ivy Bridge, non sarà possibile effettuare il underflow del buffer. Il DRNG è un po 'più veloce del bus a cui è collegato. L'effetto di tirare più dati per unità di tempo (con fili paralleli) sarà quello di aumentare il tempo di esecuzione di ogni singolo RdRand come contesa sul bus che fa sì che le istruzioni debbano attendere in coda al bus locale del DRNG. Non si può mai tirare così veloce che il DRNG subirà un underflow. Raggiungerai asintoticamente 800 MByte/s.

Anche questo non è descritto nella documentazione perché potrebbe non continuare ad essere vero nei prodotti futuri. Possiamo prevedere prodotti in cui i bus sono più veloci e i nuclei più veloci e il DRNG potrebbe essere in grado di essere trasferito. Queste cose non sono ancora note, quindi non possiamo fare affermazioni su di loro.

Ciò che resterà vero è che il ciclo di base (provare fino a 10 volte, quindi segnalare un errore nello stack) fornito nella guida degli implementatori software continuerà a funzionare nei prodotti futuri, perché abbiamo affermato che sarà così e progetteremo tutti i prodotti futuri per soddisfarlo.

Quindi no, CF = 0 non può verificarsi perché "i buffer capita di essere (temporaneamente) vuoto quando RDRAND viene invocato" su Ivy Bridge, ma potrebbe verificarsi in futuro di silicio, in modo da progettare il software di far fronte.

Answer 2

Riguardo 2: http://download.intel.com/products/processor/manual/253665.pdf, 7.3.17

Il CF indica che la richiesta di dati casuali supera il throughput del DRNG.

Per quanto riguarda 1:

Se si tratta di prestazioni si sono preoccupati, perché non legge 64bit valore casuale dal DRNG, allora si può leggere 2bits da quel 32 volte, prima di dover chiamare di nuovo l'istruzione. Non è necessario richiamare nuovo rdrand ogni volta che è necessario bit.

Answer 3

Non leggere nulla nel FIFO 4 * 128 bit nell'uscita DRNG. È certamente lì (l'ho messo lì) ma non è qualcosa che ha un effetto visibile del software. La logica dietro il DRNG non produce dati senza intoppi. Qualche volta pianifica altre cose, come il reseeding o il condizionamento, secondo la specifica SP800-90. Quindi il flusso di dati sotto carico è irregolare.

La lunghezza del buffer di 4 è stata scelta perché a 800MBytes/s (la velocità del bus collegato localmente) 4 è sufficientemente profonda da impedire l'underflow quando si tira alla massima velocità, data la peggiore escursione di pianificazione, quindi c'è un alimentazione costante da 800MByte/s senza interruzioni nell'output.

Se il bus collegato era più lento, il buffer sarebbe più corto perché un buffer più corto sarebbe stato sufficiente per impedire l'underflow.