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

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

03.09.2019 13:12, Alexey V. Vissarionov пишет:
> On 2019-09-03 10:37:07 +0300, Leonid Krivoshein wrote:
>
>   >>> Единственное, что делается ДО -- инициализация devtmpfs.
>   >> Вроде бы достаточно очевидно, что devtmpfs_mount() выполняется
>   >> до run_init_process(), но после mount_block_root()
>   > Инициализация экземпляра файловой системы внутри ядра
>   > и монтирование её в userspace -- две разные вещи.
>
> А можно ссылочки в виде имен файлов и названий функций? Мало ли,
> вдруг в ядре что-то кардинально поменялось, а я это пропустил...

Это больше к ядерщикам. Из общедоступного:

https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt
https://lwn.net/Articles/330985/
https://lwn.net/Articles/345480/
https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt


>   > Монтирование /dev в userspace инициируется процессом с PID 1
>
> Да ну?
>
> /*
>   * If configured, or requested by the commandline, devtmpfs will be
>   * auto-mounted after the kernel mounted the root filesystem.
>   */
> int devtmpfs_mount(const char *mntdir)
> {
> ...
> }

Комментарий *НАД* внимательно прочитал? Твой аргумент правильно понимать 
иначе: авто-монтирование тоже возможно. Но на практике ни разу не 
встречал. По крайней мере, во всех альтовых скриптах /dev монтируется по 
инициативе PID 1. И в других дистрибутивах тоже так. И опять же: 
авто-монтирование отработает при определённом конфигурировании только 
после монтирования rootfs. Другое дело, что...


> Это drivers/base/devtmpfs.c
>
>   > уже после того, как ядро проинициализировало initramfs, devtpmfs,
>   > нашло и запустило /sbin/init.
>
> Не... корень смонтирован, devtmpfs смонтирован - а /sbin/init еще не
> запущен.
>
> Удивительно, правда? :-)

Не удивительно, а описано в вышеприведённой статье:

After the rootfs is mounted by the kernel, the
populated tmpfs is mounted at /dev. In initramfs, it can be moved
to the manually mounted root filesystem before /sbin/init is
executed.


Есть всё же два init'а: /init (у нас в initramfs/stage1 и /sbin/init -- 
systemd в stage2).
На практике даже у нас встречал оба варианта в разных версиях.
Как предварительный mount --bind, так и отдельный экземпляр tmpfs.
Но это только при переходе из stage1 в stage2.

stage1:

http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=data/etc/rc.d/init.d/mountfs;h=8e10d7b49e1d0bf4c4cc26bb04562b94029d51a8;hb=04d5b713fccb53022fd82c222316fed8aaeebe88#l18

http://git.altlinux.org/gears/m/make-initrd.git?p=make-initrd.git;a=blob;f=data/etc/rc.d/rc.sysexec;h=292f440abfcfc0ac7b2fd32654cdb7ae15c6ffdd;hb=04d5b713fccb53022fd82c222316fed8aaeebe88

http://git.altlinux.org/gears/k/kinit-utils.git?p=kinit-utils.git;a=blob;f=kinit/run-init/runinitlib.c;h=8f1562fba7ff007cc2e719a4aa3abd4fb5a8b259;hb=f2f5cd25b9bac163e1a0e8a6e0a0878bb9373634

stage2:

http://git.altlinux.org/gears/a/alterator-pkg.git?p=alterator-pkg.git;a=blob;f=alterator-pkg/backend3/pkg-init;h=9e76ca686d4d6744d50027d884f51615c7271ac3;hb=7f733b649837a386a368c9d79366528e49200864#l40

http://git.altlinux.org/gears/s/startup.git?p=startup.git;a=blob;f=startup/rc.d/rc.sysinit;h=b332f6788ebff22cc1c88b7f0d6e5b84ff4b725b;hb=d176d6ded32e643fb4e7c45894d6c721756f8ad0#l264


>   > Никаких устройств на этом этапе ещё нет, ramfs/tpmfs в ядро
>   > вкомпилируются.
>   > Даже если не указывать путь к собственному initramfs, оно тоже в
>   > ядре имеется всегда. Пустое, без /sbin/init,
>
> Да - init/noinitramfs.c
>
>   > чтобы отработал твой любимый fallback с /dev/md0.
>
> Тут либо слово fallback не к месту, либо мысль куда-то ускользнула.

fallback -- что делать, если не задан какой-то внешний initramfs.
Твой любимый внутри-ядерный авто-поиск корневой системы, так ОК?


> [...]
>
>   > На SysV-init вероятность запуска сервиса, требующего CRNG, примерно
>   > равна нулю.
>
> В этом тысячелетии я компутеров без SSH уже не видел.

Да, но не в первые же секунды.


> [...]
>
>   >>> Блокировку на этапе загрузки можно рассматривать не только
>   >>> как баг юзабилити. В ряде задач это тоже CVE, вплоть до DoS
>   >>> для всего HA-кластера. В конце концов, подкопив энтропии,
>   >>> можно обновить состояние инициализации CRNG.
>   >> Да: низкоэнтропийная криптография - это уязвимость. Исправлять
>   >> ее будем, или как обычно?
>
> Это отнюдь не риторический вопрос.
>
>   >>> А терпеть тормоза при загрузке можно далеко не во всех
>   >>> сценариях.
>   >> При вводе системы в промышленную эксплуатацию сервер должен
>   >> быть запущен позавчера.
>
> Здесь, насколько я понимаю, возражений нет?

Готового решения в Сизиф пока никто не выложил. Безопасного решения, 
ставшего панацеей в других дистрибутивах с systemd, пока тоже не 
наблюдается. Есть только disclamers от Поттеринга и Ко.


-- 
Best regards,
Leonid Krivoshein.