[devel] [sisyphus] Не переключается в графический режим

Leonid Krivoshein klark.devel на gmail.com
Чт Ноя 8 01:19:27 MSK 2018


07.11.2018 22:41, Paul Wolneykien пишет:
> 07.11.2018 21:38, Leonid Krivoshein пишет:
>> 4. надо находить и устранять причины раннего опустошения энтропии,
>> приводящие к блокировкам.
>    Я правильно понимаю, что скоро ОС перестанет загружаться на обычном
> железе, поскольку для загрузки внезапно понадобились случайные числа?

Пока что поймать железо (в отладочных целях), где подобное проявляется 
именно с дистрибутивами Альт, нам удалось лишь единожды. По ссылкам из 
этого обсуждения видно, что проблема есть на новых ядрах в других 
дистрибутивах, так что может быть до нас просто ещё эхо не докатилось. И 
видно, что глобального решения пока не предложено. Частным порядком все 
обходятся вкорячиванием haveged/rngd, но как мы уже определились, этого 
делать не надо. Раз так, мы должны предложить альтернативу, и что-то 
подсказывает, что RND-ключик, как у Алексея, в качестве такой 
альтернативы подойдёт далеко не всем. И не просто предложить, а сделать 
автоматически применяемым в дистрибутивах решением, чтобы не было 
блокировок на старте, даже в очень редких случаях.

Однако тема имеет много практических целей. Одной уже достигли, 
определившись с haveged и rngd. Предлагаю ещё вспомнить назначение файла 
и одноимённой службы: 
https://www.freedesktop.org/software/systemd/man/systemd-random-seed.html 
. Тут ещё выяснилось, что для улучшения безопасности systemd не просто 
так собирается с libgcrypt -- он может использовать случайные числа для 
цифровой подписи каждой записи журнала. Отсюда столько интересных 
патчей, связанных с FIPS, портированных в свободную FC из RHEL. Полагаю, 
цель на раннем старте задействовать по-возможности более кошерный 
getrandom(2), на случай доступности "более естественной случайности". Но 
вот что я сейчас вижу в сизифном логе:


[    5.112227] systemd[1]: systemd 239 running in system mode. (+PAM 
+AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP 
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN 
+PCRE2 default-hierarchy=hybrid)
[    5.124337] systemd[1]: Detected architecture x86-64.
[    5.223381] random: systemd: uninitialized urandom read (16 bytes read)
[    5.223456] systemd[1]: Listening on Journal Audit Socket.
[    5.223521] random: systemd: uninitialized urandom read (16 bytes read)
[    5.223592] systemd[1]: Listening on udev Control Socket.
[    5.223656] random: systemd: uninitialized urandom read (16 bytes read)
...
[   32.283736] random: crng init done
[   32.283746] random: 7 urandom warning(s) missed due to ratelimiting


То есть, на самом раннем старте (большая часть железа здесь 
инициализируется за 5-й секундой!) журнал systemd уже нужен, но даже для 
его инициализации средствами кошерного /dev/urandom нет энтропии либо 
почему-то (!) он к этому времени всё ещё не проинициализирован. То есть, 
по логике Андрея, мы на сертифицировнных дистрах при большом желании 
сможем подделывать записи (подменять журнал) systemd, верно? Для 
гражданских-то не столь актуально. 384-бит на 5-й секунде -- не жирно так?


-- 
Best regards,
Leonid Krivoshein.



Подробная информация о списке рассылки Devel