Ентропія втрачається не тільки через /dev/{,u}random
, але ядро також бере частину. Наприклад, нові процеси мають рандомізовані адреси (ASLR), а мережевим пакетам потрібні випадкові порядкові номери. Навіть модуль файлової системи може видалити деяку ентропію. Дивіться коментарі в драйверах / char / random.c . Також зауважте, що це entropy_avail
стосується пулу введення , а не пулів виходів (в основному не блокує /dev/urandom
і блокує /dev/random
).
Якщо вам потрібно дивитися пул ентропії, не використовуйте watch cat
, що буде споживати ентропію при кожному виклику cat
. Раніше я також хотів спостерігати за цим пулом, оскільки GPG дуже повільно генерує ключі, тому я написав програму C з єдиною метою дивитися пул ентропії: https://git.lekensteyn.nl/c-files/tree /entropy-watcher.c .
Зауважте, що можуть бути фонові процеси, які також вимагають ентропії. Використовуючи траєкторії на відповідному ядрі, ви можете побачити процеси, що змінюють пул ентропії. Приклад використання, який записує всі точки трасування, пов'язані з випадковою підсистемою, включаючи callchain ( -g
) на всіх процесорах ( -a
), починаючи вимірювання через 1 секунду, щоб ігнорувати власний процес ( -D 1000
) і включаючи часові позначки ( -T
):
sudo perf record -e random:\* -g -a -D 1000 -T sleep 60
Прочитайте його за допомогою будь-якої з цих команд (замініть власника на perf.data
необхідність):
perf report # opens an interactive overview
perf script # outputs events after each other with traces
perf script
Вихід дає цікаву інформацію і показує , коли близько 8 байт (64 біт) ентропії періодично зливають на моїй машині:
kworker / 0: 2 193 [000] 3292.235908: випадковий: extra_entropy: ffffffff8173e956 пул: nbytes 8 entropy_count 921 calller _xfer_secondary_pool
5eb857 extra_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: випадковий: debit_entropy: ffffffff8173e956: debit_bits 64
5eb3e8 account.part.12 (/lib/modules/4.6.2-1-ARCH/build/vmlinux)
5eb770 extra_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: випадковий: Credit_entropy_bits: ffffffff8173e956 пул: біти 2 entropy_count 859 entropy_total 2 абонент 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)
Мабуть, це трапляється, щоб запобігти витрачанню ентропії шляхом перенесення ентропії з пулу входів у пули виходів:
/*
* 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)
{
...
}
/dev/random
зрештою, це те, що використовується для захищених криптографічних цілей, і реалізація не може дозволити собі бути наївною. Одним з пояснень може бути натякають в останній момент тут: en.wikipedia.org/wiki/Entropy_pool#Using_observed_events (починаючи з «Підтримувати потоковий шифр з ключем і вектором ініціалізації ...») -> пул замінюється , коли досить дані накопичені.