Entropie se neztrácí pouze prostřednictvím /dev/{,u}random , jádro také nějaké bere. Například nové procesy mají náhodné adresy (ASLR) a síťové pakety potřebují náhodná sekvenční čísla. Dokonce i modul souborového systému může odstranit určitou entropii. Podívejte se na komentáře v drivers/char/random.c. Všimněte si také, že entropy_avail odkazuje na vstupní fond, nikoli na výstupní fondy (v podstatě neblokující /dev/urandom a blokovací /dev/random ).
Pokud potřebujete sledovat zásobu entropie, nepoužívejte watch cat , který spotřebuje entropii při každém vyvolání cat . V minulosti jsem také chtěl sledovat tento fond, protože GPG bylo velmi pomalé při generování klíčů, a proto jsem napsal program v C s jediným cílem sledovat fond entropie:https://git.lekensteyn.nl/c-files/tree /entropy-watcher.c.
Všimněte si, že mohou existovat procesy na pozadí, které také spotřebovávají entropii. Pomocí sledovacích bodů na příslušném jádře můžete vidět procesy, které upravují fond entropie. Příklad použití, které zaznamenává všechny sledovací body související s náhodným subsystémem včetně callchainu (-g ) na všech CPU (-a ) spuštění měření po 1 sekundě, aby se ignoroval vlastní proces (-D 1000 ) a včetně časových razítek (-T ):
sudo perf record -e random:\* -g -a -D 1000 -T sleep 60
Přečtěte si jej pomocí některého z těchto příkazů (změňte vlastníka perf.data podle potřeby):
perf report # opens an interactive overview
perf script # outputs events after each other with traces
perf script výstup poskytuje zajímavý pohled a ukazuje, kdy je na mém počítači periodicky vyčerpáno asi 8 bajtů (64 bitů) entropie:
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)
Zjevně se to děje proto, aby se zabránilo plýtvání entropií přenosem entropie ze vstupní oblasti do výstupních oblastí:
/*
* 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 není nejlepším nástrojem pro sledování /dev/random jako jeden přečtený procesem je u konce v velmi krátké množství času. Nevím o dobré metodě, jak získat, jaký proces provádí čtení, ale pomocí inotify můžete sledovat pokud existuje čtení.
Zde jsou v zásadě dva způsoby:
-
Získejte souhrn po N sekundách pomocí:
inotifywatch -v -t 60 /dev/random -
Zobrazit živě přístup k událostem:
inotifywait -m --timefmt '%H:%M:%S' --format '%T: %e' /dev/random
Ani jeden vám nedá proces a druhý vám nedá velikost čtení. První vám poskytne shrnutí jako v:
total access close_nowrite open filename
18 16 1 1 /dev/random
Pokud to máte spuštěné, a proveďte dd if=/dev/random of=/tmp/foo bs=1 count=3 , máte nápad.
Stejně. To vám nezaškrtne, když jádro spotřebovává z fondu.
Pokud jde o kontrolu stavu entropie pomocí
watch cat /proc/sys/kernel/random/entropy_avail
není nejlepší nápad jako každý cat spotřebovává entropii. (Teď vidím, že se objevila další odpověď, která to také zmiňuje.) Mám pro to také nějaký kód C a včera jsem se ho pokusil najít. Uvidím, jestli to najdu a aktualizuji odpověď později.