¿Qué está comiendo mi entropía? ¿O qué muestra realmente entropy_avail?

Navega tus respuestas
14

A continuación se muestran los gráficos con el valor de /proc/sys/kernel/random/entropy_avail en una Raspberry Pi. Esta respuesta que podría no ser correcta lo describe como :

  

/proc/sys/kernel/random/entropy_avail simplemente le da la cantidad de bits que actualmente se pueden leer desde /dev/random . Los intentos de leer más que eso bloquearán hasta que haya más entropía disponible.

El patrón siempre llega al mismo patrón de sierra "estable" con una disminución de ~ 130 bits cada minuto. Si la entropía crece demasiado, algo lo "come" para volver al rango de 700-800. Si reinicio el dispositivo, la entropía se sigue consumiendo cada minuto, pero en porciones más pequeñas, lo que le permite crecer nuevamente a un rango de 700-800.

¿Cómo debo interpretar los gráficos? ¿Qué está pasando?

Mi sensación es que si solo hubo un proceso que usó un generador de números aleatorios, el entropy_avail una vez fuera de balance (usando el hardware del dispositivo) debería crecer infinitamente o disminuir al nivel de 200, cuando /dev/random dejaría de suministrar los valores.

Además, si alguno de los métodos de monitoreo (ver controles a continuación) influyó en la entropía, debería disminuir la entropía cada segundo, en lugar de dejar que crezca y caiga repentinamente a intervalos de un minuto.

(si dejo la máquina inactiva, el patrón estable de "sierra" continúa durante días, tomé las capturas de pantalla en un período de tiempo más corto)

Los gráficos

  • La máquina está inactiva durante mucho tiempo:

  • Alrededordelas19:14:45,otramáquinaaccedióaapt-cacherenelPi:laentropíacreció(supongoqueporelusodelared).Despuésdeeso,alas19:16:30,lacaídaa"niveles habituales" fue mayor de lo habitual (también es repetible, si entropy_avail crece demasiado, cae más rápido):

  • Reiniciodelamáquina,laentropíacrecehastaquealcanzaelnivel"habitual":

  • Unavezmás,alcanzaunestadoinactivo:

  • Despuésdeotroreinicio,elpuntoeneltiempodeladisminucióndeentropíacambia,peroaúnocurrecadaminuto:

Verificaciones

  • Detuve netdata (programa de monitoreo) y lo verifiqué con watch -n1 cat /proc/sys/kernel/random/entropy_avail . El valor de entropy_avail aumenta a ~ 800 y cae a ~ 680 a intervalos regulares de un minuto.

  • Por consejo " rastrear todos los procesos para acceder a / dev / random y / dev / urandom " Lo verifiqué con inotifywait (idea de un respuesta a una pregunta similar ) en Debian VM y no hay acceso a /dev/random o /dev/urandom en el momento entropy_avail gotas (de la verificación del curso registra manualmente el evento).

  • Utilicé el entropy-watcher para verificar la entropía como desaconsejado el uso de% código%. Los resultados siguen siendo consistentes con un aumento constante y una caída brusca cada 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)

Dos preguntas en Unix StackExchange que describen el mismo fenómeno (que se encuentra más adelante):

pregunta techraf 13.06.2016 - 13:22
fuente

1 respuesta

4

Primero, la afirmación de que " /proc/sys/kernel/random/entropy_avail simplemente te da el número de bits que actualmente se pueden leer desde /dev/random " es falsa.

El campo entropy_avail lee el input_pool.entropy_count , la agrupación de" salida "se refiere a la agrupación utilizada para urandom (agrupación sin bloqueo) y random (agrupación de bloqueo).

Como se menciona en esta respuesta , generar nuevos procesos consume entropía para cosas como ASLR. El programa de vigilancia genera un nuevo proceso para cada invocación, tal vez la herramienta de monitoreo haga lo mismo (¿posiblemente a través de una de las otras fuentes de monitoreo que tienen que invocar un programa externo para obtener el estado?).

Para monitorear el grupo de entropía sin vaciarlo, puede probar el programa de entropía-observador (ver respuesta vinculada).

Al observar los números entropy-watcher de cerca, parece que se pierden unos 64 bits de entropía a intervalos. Según el análisis en la otra respuesta, este parece ser el resultado de mover la entropía a un "grupo de salida" para evitar desperdiciarla. Esto se observa en Linux v4.6, las implementaciones futuras pueden ser diferentes.

Según el código fuente ( drivers/char/random.c en v4.6), puedo ver que al leer las agrupaciones de salida ( /dev/{u,}random o get_random_bytes() ) se invoca a extract_entropy{,_user} , que llama a xfer_secondary_pool y account . El grupo de bloqueo tiene la propiedad limit set ( r->limit == 1 ) que afecta a ambas funciones:

  • Para account() no devolverá datos del grupo de bloqueo si su entropía es demasiado baja. Para el grupo de salida no bloqueante, la entropía restante se consumirá pero los datos aún se devuelven.
  • xfer_secondary_pool() garantiza que haya suficiente entropía disponible en el grupo de salida. Si el grupo de salida bloqueando no tiene entropía suficiente, tomará algo del grupo de entrada (cuando sea posible).
  • xfer_secondary_pool() para el grupo de salida sin bloqueo se comporta especialmente de acuerdo con el parámetro /proc/sys/kernel/random/urandom_min_reseed_secs . Si este valor no es cero, la entropía solo se toma de la agrupación de entrada si han transcurrido al menos urandom_min_reseed_secs segundos desde la última transferencia. De forma predeterminada, este valor se establece en 60 segundos.

El último punto finalmente explica por qué ves un drenaje de entropía en el grupo de entrada cada 60 segundos. Si algunos consumidores solicitan bytes aleatorios de la agrupación de salida no bloqueante (números de secuencia TCP, ASLR, /dev/urandom , getrandom() , ...), entonces se consumirán 128 bits de la agrupación de entrada para reiniciar la salida sin bloqueo piscina.

    
respondido por el Lekensteyn 19.06.2016 - 23:13
fuente

Lea otras preguntas en las etiquetas

¿Cuánto tiempo para volver a sembrar / dev / urandom en una máquina virtual? ¿Por qué una organización como el DoD preferiría usar sus propios certificados de raíz?