L'entropie n'est pas seulement perdue via /dev/{,u}random , le noyau en prend également. Par exemple, les nouveaux processus ont des adresses aléatoires (ASLR) et les paquets réseau ont besoin de numéros de séquence aléatoires. Même le module de système de fichiers peut supprimer une certaine entropie. Voir les commentaires dans drivers/char/random.c. Notez également que entropy_avail fait référence au pool d'entrée, pas aux pools de sortie (essentiellement le /dev/urandom non bloquant et le blocage /dev/random ).
Si vous avez besoin de surveiller le pool d'entropie, n'utilisez pas watch cat , qui consommera de l'entropie à chaque invocation de cat . Dans le passé, je voulais aussi regarder ce pool car GPG était très lent à générer des clés, j'ai donc écrit un programme C dans le seul but de surveiller le pool d'entropie :https://git.lekensteyn.nl/c-files/tree /entropy-watcher.c.
Notez qu'il peut y avoir des processus d'arrière-plan qui consomment également de l'entropie. En utilisant des points de trace sur un noyau approprié, vous pouvez voir les processus qui modifient le pool d'entropie. Exemple d'utilisation qui enregistre tous les points de trace liés au sous-système aléatoire, y compris la chaîne d'appel (-g ) sur tous les processeurs (-a ) commençant à mesurer après 1 seconde pour ignorer son propre processus (-D 1000 ) et incluant les horodatages (-T ):
sudo perf record -e random:\* -g -a -D 1000 -T sleep 60
Lisez-le avec l'une de ces commandes (changez le propriétaire de perf.data au besoin):
perf report # opens an interactive overview
perf script # outputs events after each other with traces
Le perf script La sortie donne un aperçu intéressant et indique quand environ 8 octets (64 bits) d'entropie sont périodiquement drainés sur ma machine :
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)
Apparemment, cela se produit pour éviter le gaspillage d'entropie en transférant l'entropie du pool d'entrée vers les pools de sortie :
/*
* 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 n'est pas le meilleur outil pour surveiller /dev/random comme une lecture par un processus est terminée dans un très peu de temps. Je ne connais pas de bonne méthode pour obtenir quel processus effectue une lecture, mais en utilisant inotify vous pouvez surveiller si il y a une lecture.
Ici, il y a essentiellement deux façons :
-
Obtenez un résumé après N secondes avec :
inotifywatch -v -t 60 /dev/random -
Voir en direct accéder aux événements :
inotifywait -m --timefmt '%H:%M:%S' --format '%T: %e' /dev/random
Ni l'un ni l'autre ne vous donnera de processus et ce dernier ne vous donnera pas de taille de lecture. Le premier vous donnera un résumé comme dans :
total access close_nowrite open filename
18 16 1 1 /dev/random
Si vous avez cela en cours d'exécution et faites un dd if=/dev/random of=/tmp/foo bs=1 count=3 , vous voyez l'idée.
De toute façon. Cela ne vous donnera pas de ticks lorsque le noyau consommera à partir du pool.
Lorsqu'il s'agit de vérifier l'état de l'entropie à l'aide de
watch cat /proc/sys/kernel/random/entropy_avail
n'est pas la meilleure idée car chaque cat va consommer de l'entropie. (Je vois maintenant qu'une autre réponse est apparue qui mentionne également cela.) J'ai aussi du code C pour cela et j'ai essayé de le localiser hier. Je vais voir si je peux le trouver et mettre à jour la réponse plus tard.