On Mon, Nov 05, 2018 at 11:57:20PM +0300, Leonid Krivoshein wrote:
> 
> 05.11.2018 21:54, Dmitry V. Levin пишет:
> > On Mon, Nov 05, 2018 at 08:25:26PM +0300, Andrey Savchenko wrote:
> > [...]
> >> Реальная проблема в том, что на обсуждаемом этапе загрузки random
> >> ещё не нужен, но используется. Очередная глупость от systemd.
> > $ git grep -Fnw initialize_libgcrypt
> > src/basic/gcrypt-util.c:9:void initialize_libgcrypt(bool secmem) {
> > src/basic/gcrypt-util.c:30:        initialize_libgcrypt(false);
> > src/basic/gcrypt-util.h:14:void initialize_libgcrypt(bool secmem);
> > src/import/pull-job.c:324:                initialize_libgcrypt(false);
> > src/journal/fsprg.c:253:        initialize_libgcrypt(false);
> > src/journal/fsprg.c:289:        initialize_libgcrypt(false);
> > src/journal/fsprg.c:308:        initialize_libgcrypt(false);
> > src/journal/fsprg.c:335:        initialize_libgcrypt(false);
> > src/journal/fsprg.c:374:        initialize_libgcrypt(false);
> > src/journal/journal-authenticate.c:417:        initialize_libgcrypt(true);
> > src/resolve/resolved-dns-dnssec.c:852:        initialize_libgcrypt(false);
> > src/resolve/resolved-dns-dnssec.c:1171:        initialize_libgcrypt(false);
> > src/resolve/resolved-dns-dnssec.c:1284:        initialize_libgcrypt(false);
> >
> > Который из них залипает на стадии ранней загрузки?
> 
> Извиняюсь, если кого ввёл в заблуждение: там говорилось о разработчиках 
> в красной шляпе и они у себя там чего-то наотлаживали, при этом была 
> оговорка, что ничего похожего в нашем гите я не нашёл. Даже предлагал 
> решать проблему без оглядки на RedHat. Тем не менее, на моей машине:
> 
> # systemd --version
> systemd 237

В Сизифе systemd-239-alt3.

> +PAM +AUDIT +SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP 
> +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS 
> +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
> 
> # strings /lib/systemd/systemd | grep /dev/random
> /dev/random
> /dev/random
> 
> То есть, теоретически, "залипать" может "САМ"! :) Но у меня равно как и 
> у большинства ничего не залипает. IMHO: systemd может не быть 
> непосредственным виновником, но его асинхронность в ряде конфигураций 
> может привести к тому, что "залипнет". Если бы факт наполненности пула 
> можно было бы сделать зависимостью, но увы, это величина не постоянна.
> 
> Видимо этой проблеме уже присвоена CVE: 
> https://access.redhat.com/security/cve/cve-2018-1108 , её пытаются 
> решить с последними ядрами:
> 
> 4.16: https://bugzilla.redhat.com/show_bug.cgi?id=1572944
> 4.17: https://bugzilla.redhat.com/show_bug.cgi?id=1572916
> 4.18: https://bugzilla.redhat.com/show_bug.cgi?id=1639840
> 
> 4.19: 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3243a89dcbd8f5810b72ee0903d349bd000c4c9d 
> - good news, "Здравствуй, доверие"! :)
> 
> Но первый вопрос -- как это всё касается нас и касается ли вообще? Есть 
> такой прецедент:
> 
> https://lists.altlinux.org/pipermail/sisyphus/2018-November/367280.html
> 
> Логи пока доступны. Едва ли по ним будет ясна проблема. Но из них ясно, 
> что НАШ systemd использует /dev/urandom на стадии инициализации журнала. 
> Да, ещё не инициализированный, но на этом он точно не залипает. Если там 
> что и может залипать, то скорее NetworkManager или то, что зависит от 
> сети и без чего почему-то не стартуют иксы. Возможно, стоит попросить 
> отключить пока haveged и показать systemd-analaze critical-chain? Есть 
> вообще какие-то способы (от initramfs до финальной загрузки) поймать 
> всех, кто читает из /dev/random?

Пожалуйста, не надо валить всё в одну кучу.

В первую очередь воспроизведите проблему сами,
а потом уже предлагайте гипотезы и берите в руки отладчики.

И выкиньте haveged куда подальше.


-- 
ldv