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

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

On 2019-09-03 10:37:07 +0300, Leonid Krivoshein wrote:

 >>> Единственное, что делается ДО -- инициализация devtmpfs.
 >> Вроде бы достаточно очевидно, что devtmpfs_mount() выполняется
 >> до run_init_process(), но после mount_block_root()
 > Инициализация экземпляра файловой системы внутри ядра
 > и монтирование её в userspace -- две разные вещи.

А можно ссылочки в виде имен файлов и названий функций? Мало ли,
вдруг в ядре что-то кардинально поменялось, а я это пропустил...

 > Монтирование /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)
{
        int err;

        if (!mount_dev)
                return 0;

        if (!thread)
                return 0;

        err = ksys_mount("devtmpfs", mntdir, "devtmpfs", MS_SILENT, NULL);
        if (err)
                printk(KERN_INFO "devtmpfs: error mounting %i\n", err);
        else
                printk(KERN_INFO "devtmpfs: mounted\n");
        return err;
}

Это drivers/base/devtmpfs.c

 > уже после того, как ядро проинициализировало initramfs, devtpmfs,
 > нашло и запустило /sbin/init.

Не... корень смонтирован, devtmpfs смонтирован - а /sbin/init еще не
запущен.

Удивительно, правда? :-)

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

Да - init/noinitramfs.c

 > чтобы отработал твой любимый fallback с /dev/md0.

Тут либо слово fallback не к месту, либо мысль куда-то ускользнула.

 >>> К моменту запуска /sbin/init может быть даже не загружено ещё
 >>> никаких модулей.
 >> И это очень плохо. Потому что очень многие из них используют
 >> как минимум один способ (из четырех возможных) помочь ядерному
 >> ГСЧ набрать энтропию перед run_init_process()
 > К счастью, в initramfs у нас не systemd, иначе с проблемой мы
 > сталкивались бы раньше и на большем охвате железа. systemd только
 > так генерирует UUID'ы для сервисов, множество временных файлов,
 > использует внутренние хэш-таблицы и случайные числа для
 > всевозможных "сетевых" нужд. Так что плохо, да, но может быть ещё
 > хуже. Полагаю, тем, у кого нет systemd, эта проблема неведома.

Да какая разница? Запустили init - появились процессы в userspace,
которым нужен ГСЧ.

 > На SysV-init вероятность запуска сервиса, требующего CRNG, примерно
 > равна нулю.

В этом тысячелетии я компутеров без SSH уже не видел.

 >>> Процесс асинхронной инициализации хорошо виден в dmesg и
 >>> journalctl. У нас, правда, тут не systemd сейчас стартует, а
 >>> другой /sbin/init. Но надо понимать, что прохождение stage1
 >>> зависит от железа и конфигурации системы.
 >> Что ты в данном случае называешь stage1?
 > initrafms (initrd) -- первая стадия загрузки.

Пофигу - это уже userspace.

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

Это отнюдь не риторический вопрос.

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

Здесь, насколько я понимаю, возражений нет?


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