Re: [devel] rngd vs haveged vs crng (khwrngd)

[Leonid Krivoshein <klark.devel@gmail.com>]

31.08.2019 18:42, Alexey V. Vissarionov пишет:
> On 2019-08-31 17:47:06 +0300, Leonid Krivoshein wrote:
>
>   >>> systemd, равно как и ядро, не решают проблему наполнения пула
>   >>> качественной энтропией на ранней стадии загрузки
>   >> Что любопытно, ядро эту задачу прекрасно решает. Особенно если
>   >> его об этом грамотно попросить.
>   > Если имеется ввиду |rng_core.default_quality=1000| , это тоже
>   > не совсем доверенный источник,
>
> Нет - я про дисковые и сетевые контроллеры.
>
> Для первых существует специальная функция add_disk_randomness(),
> а вторые вызывают срабатывание add_interrupt_randomness() через
> handle_irq_event_percpu()
>
>   > да и про |CONFIG_RANDOM_TRUST_CPU=y| некоторые скажут, что
>   > эту хрень не надо никогда использовать.
>
> Использовать ее можно, но при соблюдении двух простых условий:
> 1. должны быть и другие источники энтропии;

Вот их нет. Совсем!

> 2. к моменту начала использования недоверенного RNG пул должен
> быть заполнен данными из других источников.

Вот он ещё не заполнен. Почти... а уже надо!


> И хорошо бы, чтобы
> продолжал хотя бы чучуть пополняться из них.
> После этого можно хоть cat /dev/zero > /dev/random запускать - на
> качество энтропии это уже не повлияет :-)

Энтропия -- это не продукт алгоритмов криптостойкого хэширования с 
начальным состоянием, это "совершенно случайные нули и единицы". Но 
вывод /dev/random и getrandom(), как я сейчас понимаю, это не чистая 
энтропия, а всё же переработанная, хотяи с заданными пороговыми 
значениями, чтобы число бит на выходе не было меньше реальной энтропии 
на входе. Если же такое качество не требуется, достаточно брать 
случайные числа из /dev/urandom, только вот с недавних пор лишь после 
инициализации начального состояния.


>   >>> остаётся два варианта: использовать дополнительный аппаратный
>   >>> (доверенный) источник
>   >> Разве что на компутерах, где живет какой-нибудь CA... для
>   >> всего остального хватает грамотно собранного ядра (которое
>   >> накапливает энтропию начиная уже где-то с третьей секунды
>   >> работы и к запуску init успевает наполнить пул).
>   > Так в том и проблема, что есть железо, где не успевает.
>
> Полностью детерминированное железо? Где? Хочу!
> Продам - стану миллиардером.

Один такой ТОНК отправлен в Обнинск. Вообще подверженное проблеме железо 
периодически всплывает. Можем завести тему в ответ на данный запрос -- 
список с наименованиями конкретных железок будет полезен многим.


>   > Только о нём спич. И здесь речь о случайных числах для запуска
>   > самого systemd, который может стартануть и быстрее, чем через
>   > три секунды.
>
> Он при всем желании не может стартануть раньше, чем ядро скажет
> run_init_process("/sbin/init");

Процессы инициализации ядра и запуска /sbin/init асинхронны. 
Единственное, что делается ДО -- инициализация devtmpfs. К моменту 
запуска /sbin/init может быть даже не загружено ещё никаких модулей. 
Процесс асинхронной инициализации хорошо виден в dmesg и journalctl.

У нас, правда, тут не systemd сейчас стартует, а другой /sbin/init. Но 
надо понимать, что прохождение stage1 зависит от железа и конфигурации 
системы. К моменту stage2, где в качестве /sbin/init будет уже systemd, 
загрузка модулей продолжится, службы же начнут запускаться по-новой.


> А к этому времени пул энтропии уже должен быть хотя бы не пустым.
> И достигается это (внезапно!) грамотной настройкой ядра.

Осталось лишь огласить способ "грамотной настройки".


>   >>> ЛИБО ослаблять энтропию программными демонами типа rngd/haveged/etc.
>   >> А вот эту срань вообще использовать нельзя. Нигде и никогда.
>
> Здесь, насколько я понимаю, возражений нет?

А что делать тем, кому "аппаратный" вариант недоступен? Блокировку на 
этапе загрузки можно рассматривать не только как баг юзабилити. В ряде 
задач это тоже CVE, вплоть до DoS для всего HA-кластера. В конце концов, 
подкопив энтропии, можно обновить состояние инициализации CRNG. А 
терпеть тормоза при загрузке можно далеко не во всех сценариях.


-- 
Best regards,
Leonid Krivoshein.