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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=cByDF0CxL5AiQnOrbf0rvlolBi3GLgMM/WAQnplxhKQ=; b=K6zFShL/Ow9C1FlroOcbJqsrqOnScx371jdULoU9+KhLyZ2YQGOeMtnnvBWBX7t48A aqqXZnY0vW9Ep0c48V13+FyspMJp7pgalgnPv/9onK38LSAuDE+poX7CK1vNTVCkLCBx Ajlt9vWvqEygmHnrh5Bu0erHEj5jYLDcjyBKB2XO8BnYG6zB5rlNdu7W7adcrpAgv5RF TuoaHCFICDy/gebK5uk2QWBMpiPXait92Q1TOZYOMBYy46TT/1L1N+/Ql1zlZCwQ+YQ3 FIbSTG4Ufc2MRpeebNMp3qjtAiQ6dsxn5rRSj8B+Y1cvY2nS8PPFHuWARozXRLm+gF9V nEsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=cByDF0CxL5AiQnOrbf0rvlolBi3GLgMM/WAQnplxhKQ=; b=DVErYF3xoG3Qp7XG8WJC1d5tqcyehbDqBIDIVAAsrs4dZUUaOKZIwA+8ZOjtmRfm8o VczoVj5lxzcjsUZ7q7cZDYH1JvrAChlFjPoAU0jmvTYdJB6RFK2u0gxfLuBmWF0lWhdJ lmEqd767QwB/X84PMBVgG3sAciFd0wFk38hFlboOnPaAIZOwxPFSAxXeSIO6m6uDbt22 BrNziB/FWMXqTNw0aQ3aLxDhocVqcDhjaYTNqspetz1TiZ9d7E6x/fms0UBXHEvVfSs6 zi0rLi69fnuEG+a+J2pZZJztNjACKEGkzJMoaZB+5otoIsnTPICW9GdzjITaUFSoqAZ9 6kew== X-Gm-Message-State: APjAAAXuW/aPUbWVO3i0fCuwpf156GSLhq0O23lXqIpk+pXYdtBv5rJ4 ivA+/KyFzbe5/Fa5ZkMYMjaa1IBi X-Google-Smtp-Source: APXvYqwGONBROXhFhAmdHNvUz0084xb3h+E/GrkMw1r6/bTPCvCeTxgWHqznfP4CYov0t5b9H8URBw== X-Received: by 2002:a2e:2c16:: with SMTP id s22mr9940808ljs.148.1567544104027; Tue, 03 Sep 2019 13:55:04 -0700 (PDT) To: devel@lists.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> <20190903101217.GT12903@altlinux.org> From: Leonid Krivoshein Message-ID: <753bcd80-5b91-7616-be80-d80572c8818e@gmail.com> Date: Tue, 3 Sep 2019 23:51:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20190903101217.GT12903@altlinux.org> Content-Type: text/plain; charset=koi8-r; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru 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 20:55:07 -0000 Archived-At: List-Archive: List-Post: 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.