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

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

03.09.2019 11:49, Paul Wolneykien пишет:
> 03.09.2019 10:02, Leonid Krivoshein пишет:
>> 03.09.2019 01:25, Paul Wolneykien пишет:
>>> 03.09.2019 00:31, Leonid Krivoshein пишет:
>>>>>> И здесь речь о случайных числах для запуска
>>>>>> самого systemd, который может стартануть и быстрее, чем через
>>>>>> три секунды.
>>>     Мне тоже стало интересно, о чём вы тут спорите.
>> В данном случае речь о проблемах, обсуждаемых в статье:
>> https://systemd.io/RANDOM_SEEDS -- разработчики systemd заверяют, что
>> случайные числа на раннем этапе запуска им тоже нужны, но их источник не
>> обязан быть криптографического качества.
>    И, стало быть, разницы между /dev/random и /dev/urandom им
> недостаточно? Одного слишком много — встаёт колом, другой — слишком
> низкого качества. В таком случае им нужен третий — какой-нибудь
> /dev/boot_random, качество и количество энтропии в котором будет
> необходимого и достаточного качества.
>    Но мне кажется, что это ошибка и вполне опасная. В вопросах
> безопасности "серединный путь" не годится, я считаю. Если уж
> пользователь выбрал ОС с криптозагрузкой (назовём это так), то
> требования должны быть высокими во избежание. С быстрой загрузкой без
> спецоборудования это вряд ли совместимо и поэтому не нужно пытаться
> делать вид, что это так.

В целом, согласен. Статус этого документа не совсем ясен. Я бы назвал 
это "отмазками". Преподносится как информация для разработчиков. И 
действительно из этого документа можно задействовать множество способов, 
где железо позволяет. А где не позволяет, здесь говорится, чем грозит и 
что это будет вашим риском. Всё честно.


>
>> В принципе, даже 1 бит энтропии
>> вместе с текущим временем и glibc rand() это обеспечивают. Поэтому речь
>> явно не только запуске самого systemd, иначе бы так сильно не
>> заморачивались.
>    А кто ещё, sshd?

Нет, даже при запуске ssh-keygen -A используется /dev/urandom для 
инициализации внутреннего ГПСЧ. Возможности сменить источник СЧ я там не 
увидел. Но в командной строке есть возможность использовать готовый 
сертификат. Тот факт, что при запуске службы возможна генерация 
криптографических пар таким вот генератором меня тоже удивляет. Тут надо 
иметь ввиду, что зависимость от /dev/urandom порождает меньшее из зол: с 
какого-то ядра (4.16 кажись) принято блокировать обращение к 
/dev/urandom до полной инициализации пула ядра. Судя по логам, первым, 
кто оттуда хапает трижды по 16 байт -- systemd. В дальнейшем в лог 
выводятся лишь предупреждения о недостатке энтропии, но блокировки не 
выполняется. И нет, на практике с sshd проблем не вылазило ни разу. 
Проблемы вылазили и будут вылазить со всей криптухой, начиная с 
cryptsetup до всяких keyring'ов.


> Почему с ним раньше проблем не возникало?

Тут gremlin@ уже верно ответил. Лишь добавлю деталей: массовый переход с 
HDD на SSD/NVME (прерываний в первых секундах старта ощутимо меньше), 
более быстрый параллельный запуск. Раньше можно было увидеть загруженный 
desktop MATE за 14-20 секунд, на некоторых новых машинках уже 5-7 
секунд. Раньше загрузка была последовательной, сам SysVinit не требовал 
ГПСЧ.


> Ну и опять
> же, на мой взгляд это проблема, в первую очередь, в диагностике. Если
> какая-то служба долго не стартует, то в журнале должно быть что-то про
> нехватку энтропии.

Тут сложнее. Никто (systemd тоже) не может заранее предугадать, какая из 
служб попросит у ядра getrandom(), а на время блокировки все зависимые 
службы не будут грузиться. Например, при запуске графического сеанса с 
включенным авто-входом в MATE, стартует gnome-keyring, и вместо рабочего 
стола несколько минут чёрный экран. В журнале dmesg через несколько 
минут может появиться одна запись. Типа crng init done. Тогда процесс 
загрузки продолжится. Ускорить помогает хаотичное движение мышкой и 
нажатие клавиш.


-- 
Best regards,
Leonid Krivoshein.