GNU/Linux >> Tutoriales Linux >  >> Linux

¿Qué sigue drenando la entropía?

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:

  1. Obtenga un resumen después de N segundos con:

    inotifywatch -v -t 60 /dev/random 
    
  2. 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.


Linux
  1. Linux:¿Diferencia entre /dev/console, /dev/tty y /dev/tty0?

  2. ¿En qué sistemas es diferente //foo/bar de /foo/bar?

  3. ¿Qué es diferente entre /bin/false y /sbin/nologin como shell del usuario nologin?

  4. ¿Cuáles son los significados de /usr/sbin, /usr/local/sbin y /usr/local/bin?

  5. DD de /dev/zero a /dev/null... lo que realmente sucede

¿Qué es '/dev/null 2&1' en Linux?

¿Qué es /bin/verdadero?

Instalar binarios en /bin, /sbin, /usr/bin y /usr/sbin, interacciones con --prefix y DESTDIR

¿Cuándo debo usar /dev/shm/ y cuándo debo usar /tmp/?

unix:///var/run/supervisor.sock no hay tal archivo

¿Por qué se requieren < o > para usar /dev/tcp?