From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on sa.local.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=unavailable autolearn_force=no version=3.4.1 Date: Tue, 3 Sep 2019 13:12:17 +0300 From: "Alexey V. Vissarionov" To: ALT Linux Team development discussions Message-ID: <20190903101217.GT12903@altlinux.org> References: <20190531105614.GD27835@altlinux.org> <975ac233-dc84-d9eb-1d24-975ee807c075@basealt.ru> <20190831123520.GD12903@altlinux.org> <936a2336-e8c6-8274-37cf-a8059ee9bf44@gmail.com> <20190831154243.GE12903@altlinux.org> <7e2bba2a-867f-b8a0-6e27-1a07521e13fb@gmail.com> <20190902235913.GO12903@altlinux.org> <12b305ed-4e3c-c4c1-7d19-17649f0817fe@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <12b305ed-4e3c-c4c1-7d19-17649f0817fe@gmail.com> Subject: Re: [devel] rngd vs haveged vs crng (khwrngd) X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Sep 2019 10:12:21 -0000 Archived-At: List-Archive: List-Post: 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