Cosa sta mangiando la mia entropia? O cosa mostra davvero entropy_avail?

Question

Cosa sta mangiando la mia entropia? O cosa mostra davvero entropy_avail?

#1 da (5 voti)

15

Di seguito sono riportati i grafici con il valore di /proc/sys/kernel/random/entropy_avail su un Raspberry Pi. Questa risposta ^{che potrebbe non essere corretta} la descrive come :

/proc/sys/kernel/random/entropy_avail simply gives you the number of bits that can currently be read from /dev/random. Attempts to read more than that will block until more entropy becomes available.

Lo schema ha sempre lo stesso schema di seghe "stabile" con una diminuzione di ~ 130 bit ogni singolo minuto. Se l'entropia cresce troppo, qualcosa sta "mangiando" per tornare all'intervallo 700-800. Se riavvio il dispositivo, l'entropia viene ancora mangiata ogni minuto, ma in parti più piccole, consentendo così di crescere nuovamente fino a 700-800 range.

Come posso interpretare i grafici? Cosa sta succedendo?

La mia sensazione è che se ci fosse solo un processo che usa un generatore di numeri casuali, il entropy_avail una volta sbilanciato (usando l'hardware del dispositivo) dovrebbe crescere all'infinito o diminuire al livello di 200, quando /dev/random smetterebbe di fornire i valori.

Inoltre, se uno qualsiasi dei metodi di monitoraggio (vedi controlli di seguito) influenza l'entropia, dovrebbe piuttosto diminuire l'entropia ogni secondo, anziché lasciarlo crescere e cadere improvvisamente ad intervalli di un minuto.

^{(se lascio la macchina inattiva, il modello stabile "visto" continua per giorni, ho preso gli screenshot in un periodo di tempo più breve)}

I grafici

La macchina è inattiva da molto tempo:
Versole19:14:45un'altramacchinaaccedevaaapt-cachersullaPi-entropiacresciuta(suppongodall'usodellarete).Dopodichéalle19:16:30ilcalodei"soliti livelli" è stato maggiore del solito (è anche ripetibile - se entropy_avail diventa troppo grande, scende più velocemente):
Riavvialamacchina,l'entropiacrescefinoaraggiungereillivello"normale":
Ancoraunavoltaraggiungeunostatodiinattività:
Dopounaltroriavvio,ilpuntoneltempodell'entopiadiminuiscelemodifiche,masiverificacomunqueogniminuto:

Verifica

Hointerrotto netdata (programma di monitoraggio) e controllato con watch -n1 cat /proc/sys/kernel/random/entropy_avail . Il valore di entropy_avail aumenta a ~ 800 e scende a ~ 680 a intervalli regolari di un minuto.
Per consiglio " traccia tutti i processi per accedere a / dev / random e / dev / urandom " Ho controllato con inotifywait (idea da un answer a una domanda simile ) su Debian VM e non vi è alcun accesso a /dev/random o /dev/urandom al momento entropy_avail gocce (di ovviamente il controllo registra l'evento manualmente.

Ho usato il entropy-watcher per controllare l'entropia come sconsigliato di usare% codice%. I risultati sono ancora coerenti con un costante aumento e una brusca caduta ogni singolo minuto:

833 (-62)
836 (+3)
838 (+2)
840 (+2)
842 (+2)
844 (+2)
846 (+2)
848 (+2)
850 (+2)
852 (+2)
854 (+2)
856 (+2)
858 (+2)
860 (+2)
862 (+2)
864 (+2)
866 (+2)
868 (+2)
871 (+3)
873 (+2)
811 (-62)

Due domande su Unix StackExchange che descrivono lo stesso fenomeno (trovato più tardi):

random entropy

posta techraf 13.06.2016 - 13:22

fonte

1 risposta

Leggi altre domande sui tag random entropy

È possibile eseguire l'iniezione a bassa energia Bluetooth? Perché un'organizzazione come la DoD preferisce utilizzare i propri certificati di root?

score 5 · Accepted Answer

Innanzitutto, l'affermazione che " /proc/sys/kernel/random/entropy_avail ti dà semplicemente il numero di bit che possono essere letti attualmente da /dev/random " è falso.

Il campo entropy_avail legge input_pool.entropy_count , il pool" output "fa riferimento al pool utilizzato per urandom (pool non bloccante) e random (blocco pool).

Come menzionato in questa risposta , la generazione di nuovi processi consuma entropia per cose come ASLR. Il programma di controllo genera un nuovo processo per ogni invocazione, forse lo strumento di monitoraggio fa lo stesso (probabilmente tramite una delle altre sorgenti di monitoraggio che devono richiamare un programma esterno per ottenere lo stato?).

Per monitorare il pool di entropia senza scaricarlo, puoi provare il programma entropy-watcher (vedi risposta collegata).

Guardando i numeri entropy-watcher da vicino sembra che si perdano circa 64 bit di entropia a intervalli. Sulla base dell'analisi nell'altra risposta, questo sembra essere il risultato del movimento dell'entropia in un "pool di output" per evitare di sprecarlo. Ciò è stato osservato su Linux v4.6, le future implementazioni potrebbero essere diverse.

Sulla base del codice sorgente ( drivers/char/random.c nella v4.6), posso vedere che la lettura dei lotti di output ( /dev/{u,}random o get_random_bytes() ) richiama extract_entropy{,_user} che chiama xfer_secondary_pool e account . Il pool di blocchi ha la proprietà limit set ( r->limit == 1 ) che influenza entrambe le funzioni:

Per account() non restituirà dati dal pool di blocchi se la sua entropia è troppo bassa. Per il pool di output non bloccante, l'entropia rimanente verrà consumata ma i dati verranno comunque restituiti.
xfer_secondary_pool() assicura che entropy sia disponibile nel pool di output. Se il pool di output blocco ha un'entropia insufficiente, ne prenderà un po 'dal pool di input (quando possibile).
xfer_secondary_pool() per il pool di output non bloccante si comporta in modo specifico secondo il parametro /proc/sys/kernel/random/urandom_min_reseed_secs . Se questo valore è diverso da zero, entropy viene prelevato dal pool di input solo se è trascorso almeno urandom_min_reseed_secs secondi dall'ultimo trasferimento. Di default questo valore è impostato su 60 secondi.

L'ultimo punto spiega infine perché si vede un drenaggio di entropia nel pool di input ogni 60 secondi. Se alcuni utenti richiedono byte casuali dal pool di output non bloccante (numeri di sequenza TCP, ASLR, /dev/urandom , getrandom() , ...), allora 128 bit verranno consumati dal pool di input per eseguire il reseeding dell'output non bloccante piscina.