Re: [devel] rngd vs haveged vs crng

["Alexey V. Vissarionov" <gremlin@altlinux.org>]

On 2019-05-28 02:53:12 +0300, Leonid Krivoshein wrote:

 >>> В копилку дополнительных решений. Случайно наткнулся на
 >>> специальный клиент-сервер :)
 >> То есть сперва создать проблему на ровном месте,
 >> затем героически её решать.
 > Справедливости ради: специально её не создавали, так уж
 > сложилось.

Именно создали.

 > Рынок жаждет быстрых компьютеров, быстрых SSD.

И они появились.

 > Overal Perfomance Index определяется отнюдь не скоростью
 > загрузки и временем отклика на данную команду, но обыватель
 > не любит ждать и ему важнее эти два "субъективных" показателя,

Обывателям вообще начхать на любые показатели - им нужны котики.

 > конечно, непосредственно о распараллеливании загрузки никто
 > особо не думает.

Разумеется: основная задача - обеспечить запуск демонов в нужной
последовательности с учетом их взаимных зависимостей (httpd надо
запустить после postgresql, но до nginx, так как CMS сайтов нужен
доступ к БД, а FE требует работающего BE), а распараллеливание
загрузки - не более, чем приятный побочный эффект.

 > Однако init-системы начали вырастать одна за другой в угоду
 > этим хотелкам рынка, systemd -- не первая, и наверняка не
 > последняя. Скорее всего, ещё и не самая плохая реализация

На данный момент - самая.

 > параллельной загрузки.

Еще раз: не параллельной загрузки, а запуска демонов с учетом их
взаимных зависимостей.

 > Самой удачной она могла бы стать, если бы не ломала надёжности,

Собственно, этой причины уже достаточно для того, чтобы избегать
этого поделия в промышленных системах.

 > не создавала бы гонок на ровном месте,

Для этого и нужны взаимные зависимости. И, кстати, их можно легко
реализовать даже на основе SysVinit - для этого достаточно сделать
обязательным `service $name status` с унифицированным выводом
("unknown", "disabled", "stopped", "failed", "running").

 > позволяла бы работать с разными профилями надёжности

Эээээто как? Отключать глюкодром там, где надо сделать хорошо? :-)

 > и совместимости.

С чем?

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

А для остальных - "пипл хавает"?

 > Но ведь даже не systemd стал проблемой.

Именно он и стал. Из-за головожопости разработчиков, у которых
фантазия улетела в дальние дали и окончательно оторвалась от
реальности - именно это мы наблюдаем в ситуации, когда во имя
скорости загрузки эти (выражусь дипломатично) дебилы жертвуют
надежностью и безопасностью.

 > Не было бы его, здесь был бы upstart или любой другой имярек.

Что любопытно, в upstart это настолько явно не проявляется.

 > Просто, с одной стороны, компьютеры и диски стали быстрее,

Да. Нужно успевать.

 > система загрузки стала слишком непоследовательной,

И что? Пока не прочитали из /proc/sys/kernel/random/poolsize
число 4096 (что означает полностью заполненный пул энтропии) -
просто не запускаем ничего. По буквам: Николай, Иван, Харитон,
Ульяна, Яков. Повторяю: ничего.

А, ну да... это же замедлит загрузку, и пользователю придется
(о ужас!) подождать несколько секунд...

 > с другой -- апстрим ядра закрутил гайки с CPRNG.

Да ничего они там особо не крутили... немного поменяли логику
работы и вместо SHA2 теперь используют игрушечный poly1305.

 > И проблема вылазит точечно, даже виртуалок это больше
 > касается. Потому что и там прогресс, и там тоже закрутили.

А нефиг их на горячуу клонировать...

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

Хороший. А теперь подумай, как ты от него избавишься... ну,
например, в эталонном образе виртуалки.

Или будешь плодить кучу хостов с одинаковыми ключами? :-)

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

Откуда и как мы это можем узнать точно?

 > Будучи запущенными в первые несколько секунд, это создаст
 > проблему. Оценить текущий пул через sysfs мы можем, время
 > от начала запуска известен. Для таких программ создаются
 > фэйки-обёртки, выполняющие их отложенный запуск. А systemd
 > пусть думает, что всё уже случилось.

Это даже не просто костыль - это специально сломать ногу, а
потом компенсировать это костылем.

 > Если для ряда таких программ заблокировать запуск полностью
 > возможно без ущерба для загрузки, значит, сразу после логина
 > юзера с uid 500

А почему не 512? :-)

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

И усер такой: http://pics.rsh.ru/img/sova_pwivfaew.jpg

 > Для таких программ, как gnome-keyring, если создавать
 > временное хранилище на основе ненадёжных данных

... то лучше вообще не создавать такое хранилище.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net