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=-3.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.1 Date: Wed, 12 Feb 2025 01:27:00 +0300 From: "Alexey V. Vissarionov" To: ALT Linux Team development discussions Message-ID: <20250211222700.GA28754@altlinux.org> References: <20250211214112.5a70e33ea00da2d020496059@altlinux.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250211214112.5a70e33ea00da2d020496059@altlinux.org> Subject: Re: [devel] =?koi8-r?b?a2VybmVsOiDP1MvMwN7J1NggcmFuZG9tLnRydXN0KiDJ?= =?koi8-r?b?2iDLz9LPwsvJ?= 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, 11 Feb 2025 22:27:09 -0000 Archived-At: List-Archive: List-Post: Good ${greeting_time}! On 2025-02-11 21:41:12 +0300, Andrey Savchenko wrote: > Начиная с ядра 6.10 опции CONFIG_RANDOM_TRUST_CPU больше нет Да и пусть с ней. > Теперь доверие к RDRAND и энтропии от загрузчика включено > по-умолчанию Вполне себе источники энтропии. Если не использовать их как единственные - ничуть не хуже остальных. > И можно выключить только по: random.trust_cpu=off > random.trust_bootloader=off > Поэтому и пишу сюда, а не в devel-kernel, потому что изменения > нужны на уровне параметров ядра со стороны загрузчика. CONFIG_CMDLINE > сложно рассматривать включенный из коробки random.trust_cpu > иначе, чем бэкдор. У Intel дела не сильно лучше вспоминаем > материалы Сноудена. > И с random.trust_bootloader не лучше вспоминаем качество кода > вендорских реализаций UEFI и количество проблем в них. Повторю, так бывает в единственном случае - когда нет никаких других источников. Ой, а у нас их действительно нет... И что же это за вредители такие их все массово поотключали, да еще и не дают ядру набрать энтропию? :-) > Поэтому предлагаю: во всех загрузчиках (grub, efi, lilo, extlinux, > что там ещё у нас используется) добавить в kernel cmdline: > random.trust_cpu=off random.trust_bootloader=off Отказать, отменить и запретить. Если по каким-то причинам (религиозным, наверное) совсем уж претит использовать дополнительно от двух до десятка источников энтропии, такой костыль действительно можно применить, но в CONFIG_CMDLINE: это обеспечит его использование только в уязвимых ядрах (6.12 моей сборки данная проблема не затрагивает, если что). И если уж туда лезть, то сразу написать ro panic=30 rootdelay=10 > Да, у пользователей систем с сотнями контейнеров, где systemd > выедает всю энтропию на старте системы, могут быть задержки > в загрузке. Запустил в одном терминале dd bs=1M if=/dev/random of=/dev/null , а в другом watch cat /proc/sys/kernel/random/entropy_avail Устойчиво выдает 256, не шелохнется. Даже если аппаратный ГСЧ из УПШ выдернуть. Вопрос со звездочкой^{\tm}: как я этого добился и откуда берется нужное количество случайных битов для подпитки ядерного генератора? Подсказка: наполнение пула энтропии у меня происходит на шестой секунде загрузки ядра. > На таких системах пользователи могут убрать эти параметры ценой > безопасности своих систем, что печально, т.к. обычно это хостинг. Достаточно, чтобы в момент запуска init ядерный пул энтропии был (1) наполнен (2) с использованием хотя бы одного доверенного источника (а лучше трех-пяти). Дальше работает гаммирование с подмешиванием случайных битов через add_hwgenerator_randomness(), add_device_randomness(), add_interrupt_randomness() итд. > Правильным лечением будет исправлять systemd, но ввиду острой > нехватки галоперидола у его ключевых разработчиков это > представляется затруднительным. А еще это веский аргумент продолжать поддерживать sysVinit. -- Alexey V. Vissarionov gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net