Re: [devel] rngd vs haveged vs crng

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

27.05.2019 14:59, Michael Shigorin пишет:
> On Thu, May 23, 2019 at 02:08:28AM +0300, Alexey Shabalin wrote:
>> В копилку дополнительных решений. Случайно наткнулся на
>> специальный клиент-сервер :)
> То есть сперва создать проблему на ровном месте,
> затем героически её решать.

Справедливости ради: специально её не создавали, так уж сложилось. Рынок 
жаждет быстрых компьютеров, быстрых SSD. Overal Perfomance Index 
определяется отнюдь не скоростью загрузки и временем отклика на данную 
команду, но обыватель не любит ждать и ему важнее эти два "субъективных" 
показателя, конечно, непосредственно о распараллеливании загрузки никто 
особо не думает. Однако init-системы начали вырастать одна за другой в 
угоду этим хотелкам рынка, systemd -- не первая, и наверняка не 
последняя. Скорее всего, ещё и не самая плохая реализация параллельной 
загрузки. Самой удачной она могла бы стать, если бы не ломала 
надёжности, не создавала бы гонок на ровном месте, позволяла бы работать 
с разными профилями надёжности и совместимости. Для бывалых никакого 
значения не имеет скорость загрузки, надёжность важнее.

Но ведь даже не systemd стал проблемой. Не было бы его, здесь был бы 
upstart или любой другой имярек. Просто, с одной стороны, компьютеры и 
диски стали быстрее, система загрузки стала слишком непоследовательной, 
с другой -- апстрим ядра закрутил гайки с CPRNG. И проблема вылазит 
точечно, даже виртуалок это больше касается. Потому что и там прогресс, 
и там тоже закрутили.


> Лёш, чинить journald апстрим часом не собирается?
> Например, на предмет ручки "не подписывать логи",
> "подписывать, если есть энтропия", "подписывать всегда"?

Выходит, в первую очередь именно мы должны думать, как компоновать 
системы, чтобы не было потребителей энтропии на раннем старте. 
Персонально отлавливать и отстреливать. Хороший пример с ssh-keygen -A.


> По умолчанию в "обычных" выпусках, как мне кажется,
> работоспособность системы в течение разумного времени
> после включения/перезагрузки важнее, чем подписи,
> которые не проверит/посмотрит никто.

Все варианты решения уже известны и обсуждались много раз. Можно ещё 
один вариант рассмотреть. Допустим, мы уже точно знаем, какие приложения 
сколько выжрут энтропии. Будучи запущенными в первые несколько секунд, 
это создаст проблему. Оценить текущий пул через sysfs мы можем, время от 
начала запуска известен. Для таких программ создаются фэйки-обёртки, 
выполняющие их отложенный запуск. А systemd пусть думает, что всё уже 
случилось. Если для ряда таких программ заблокировать запуск полностью 
возможно без ущерба для загрузки, значит, сразу после логина юзера с uid 
500 чтобы вылазило системное предупреждение, типа: внесите такие-то 
изменения в свои настройки или мы и дальше будем блокировать запуск 
таких-то приложений. Для таких программ, как gnome-keyring, если 
создавать временное хранилище на основе ненадёжных данных -- тоже сразу 
чтобы прилетало уведомление юзеру, но запуск не блокировался. На худой 
конец, не создавать это временное хранилище. Короче, отстреливать 
индивидуально или как-то так.


-- 
Best regards,
Leonid Krivoshein.