La entropía no solo se pierde a través de /dev/{,u}random
, el kernel también toma algo. Por ejemplo, los nuevos procesos tienen direcciones aleatorias (ASLR) y los paquetes de red necesitan números de secuencia aleatorios. Incluso el módulo del sistema de archivos puede eliminar algo de entropía. Vea los comentarios en drivers/char/random.c. También tenga en cuenta que entropy_avail
se refiere al grupo de entrada, no a los grupos de salida (básicamente el /dev/urandom
sin bloqueo y el bloqueo /dev/random
).
Si necesita ver el grupo de entropía, no use watch cat
, que consumirá entropía en cada invocación de cat
. En el pasado, también quería ver este grupo, ya que GPG era muy lento para generar claves, por lo que escribí un programa en C con el único propósito de ver el grupo de entropía:https://git.lekensteyn.nl/c-files/tree /entropy-watcher.c.
Tenga en cuenta que puede haber procesos en segundo plano que también consumen entropía. Usando puntos de seguimiento en un núcleo apropiado, puede ver los procesos que modifican el grupo de entropía. Ejemplo de uso que registra todos los puntos de seguimiento relacionados con el subsistema aleatorio, incluida la cadena de llamadas (-g
) en todas las CPU (-a
) comenzando a medir después de 1 segundo para ignorar su propio proceso (-D 1000
) e incluyendo marcas de tiempo (-T
):
sudo perf record -e random:\* -g -a -D 1000 -T sleep 60
Léalo con cualquiera de estos comandos (cambiar propietario de perf.data
según sea necesario):
perf report # opens an interactive overview
perf script # outputs events after each other with traces
El perf script
la salida brinda una perspectiva interesante y muestra cuándo se agotan periódicamente alrededor de 8 bytes (64 bits) de entropía en mi máquina:
kworker/0:2 193 [000] 3292.235908: random:extract_entropy: ffffffff8173e956 pool: nbytes 8 entropy_count 921 caller _xfer_secondary_pool 5eb857 extract_entropy (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 5eb984 _xfer_secondary_pool (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 5ebae6 push_to_pool (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 293a05 process_one_work (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 293ce8 worker_thread (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 299998 kthread (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 7c7482 ret_from_fork (/lib/modules/4.6.2-1-ARCH/build/vmlinux) kworker/0:2 193 [000] 3292.235911: random:debit_entropy: ffffffff8173e956: debit_bits 64 5eb3e8 account.part.12 (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 5eb770 extract_entropy (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 5eb984 _xfer_secondary_pool (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 5ebae6 push_to_pool (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 293a05 process_one_work (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 293ce8 worker_thread (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 299998 kthread (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 7c7482 ret_from_fork (/lib/modules/4.6.2-1-ARCH/build/vmlinux) ... swapper 0 [002] 3292.507720: random:credit_entropy_bits: ffffffff8173e956 pool: bits 2 entropy_count 859 entropy_total 2 caller add_interrupt_randomness 5eaab6 credit_entropy_bits (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 5ec644 add_interrupt_randomness (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 2d5729 handle_irq_event_percpu (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 2d58b9 handle_irq_event (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 2d8d1b handle_edge_irq (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 230e6a handle_irq (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 7c9abb do_IRQ (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 7c7bc2 ret_from_intr (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 6756c7 cpuidle_enter (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 2bd9fa call_cpuidle (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 2bde18 cpu_startup_entry (/lib/modules/4.6.2-1-ARCH/build/vmlinux) 2510e5 start_secondary (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
Aparentemente, esto sucede para evitar el desperdicio de entropía al transferir entropía del grupo de entrada a los grupos de salida:
/*
* Credit (or debit) the entropy store with n bits of entropy.
* Use credit_entropy_bits_safe() if the value comes from userspace
* or otherwise should be checked for extreme values.
*/
static void credit_entropy_bits(struct entropy_store *r, int nbits)
{
...
/* If the input pool is getting full, send some
* entropy to the two output pools, flipping back and
* forth between them, until the output pools are 75%
* full.
*/
...
schedule_work(&last->push_work);
}
/*
* Used as a workqueue function so that when the input pool is getting
* full, we can "spill over" some entropy to the output pools. That
* way the output pools can store some of the excess entropy instead
* of letting it go to waste.
*/
static void push_to_pool(struct work_struct *work)
{
...
}
lsof no es la mejor herramienta para monitorear /dev/random
como uno leído por un proceso ha terminado en un muy breve cantidad de tiempo. No conozco un buen método para obtener qué proceso está haciendo una lectura, pero usando inotify
puede monitorear si hay una lectura.
Aquí hay básicamente dos formas:
-
Obtenga un resumen después de N segundos con:
inotifywatch -v -t 60 /dev/random
-
Ver en vivo acceder a eventos:
inotifywait -m --timefmt '%H:%M:%S' --format '%T: %e' /dev/random
Tampoco le dará proceso y el último no le dará tamaño de lectura. El primero le dará un resumen como en:
total access close_nowrite open filename
18 16 1 1 /dev/random
Si tienes eso ejecutándose y haz un dd if=/dev/random of=/tmp/foo bs=1 count=3
, entiendes la idea.
De todos modos. Esto no le dará tics cuando el kernel consume del grupo.
Cuando se trata de verificar el estado de la entropía usando
watch cat /proc/sys/kernel/random/entropy_avail
no es la mejor idea ya que cada cat
va a consumir entropía. (Ahora veo que apareció otra respuesta que también menciona esto). También tengo un código C para esto y traté de localizarlo ayer. Veré si puedo encontrarlo y actualizaré la respuesta más tarde.