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=0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FUZZY_XPILL autolearn=no 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=/HyuhlkWQE3xfrNLeGYvg7Do3F1RZ0RnN+/X7JK+yXA=; b=q7YpjysY0T8u4qxdz9hE6pu+9oXn75B7iF8Hd+iZ8zkGlwRU9CZLr0fCmsXmZr83Eq NdWNsO07aDBCoYKYp5P7f5FodIeeYOVk0+P6P3UClzdzJDUd3L26a2eqTNCDWpNaymC/ lk153jx2PkcepqfaOlqlrNQu6LXxK88o87hUb3zatqPKU9RdltRgoGzy4xWzURjDvNBT CWEdreamdGxK9BnkcnW3DeqHfv7nqpwsrnrI3+zOO3NzfHmtwBjM9l9DguaJzQyC/cYo 5Han1XE9hNgQWaFnS9T+Jidg0zvn2tEXCqB+JEWx+CbyNWd+ZwnZRkt1y2kL1Y7QUY0W vpkA== 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=/HyuhlkWQE3xfrNLeGYvg7Do3F1RZ0RnN+/X7JK+yXA=; b=IB5YquEiiWtMavVU+bHDY8e0z/nlFVDm32NlqfzJyU7ik/R31K/4+T4F7D19CZ5LR1 Q8NdEtPMGgBKMpCoMfYxk6+WYIDD7kNALbcbPI2YwutDGtfJzWPGB8KcctMRTU99JU+U 6+CCuCvauteRqM1jwtHQiAsRtc3JFPe1fA07BGPZTgzoNGhbay69yKhIjiGLW/iPE4O8 KTYO3pbAYIc4EM/pL1nHblV83iy/Kb7NIJABX3D2ENau+RCpjS4CYIfCJ50G35a5JWWZ If2cJ3lXN90TZ2Xee+Nq29jRAf0Dj95dyPdpBYJ8sk/cc/RwyIGnx6x/zIoW4lDjVtQt 5Dtw== X-Gm-Message-State: APjAAAWQZxNafXsf2d3uGGzo71fcmUCUAt1rYUz/PAzUqGmED1Xf9B0g ynhjDkO/3f2hWTZFPTYT/upPkKQb X-Google-Smtp-Source: APXvYqya12j+HhVL3NvNRFVRTOENZaRANMvXuEvgL2MyiQio7hPiZy6kSLi6PBRL02uXieQRB5YB6Q== X-Received: by 2002:a19:f819:: with SMTP id a25mr6569447lff.45.1567460078438; Mon, 02 Sep 2019 14:34:38 -0700 (PDT) To: devel@lists.altlinux.org References: <4beb559f-4864-35a2-b8c8-3fa0909d6069@basealt.ru> <20190530164054.GA27835@altlinux.org> <4041b3c1-b134-9720-0f01-1a2527ed1721@basealt.ru> <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> From: Leonid Krivoshein Message-ID: <7e2bba2a-867f-b8a0-6e27-1a07521e13fb@gmail.com> Date: Tue, 3 Sep 2019 00:31:05 +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: <20190831154243.GE12903@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: Mon, 02 Sep 2019 21:34:42 -0000 Archived-At: List-Archive: List-Post: 31.08.2019 18:42, Alexey V. Vissarionov пишет: > On 2019-08-31 17:47:06 +0300, Leonid Krivoshein wrote: > > >>> systemd, равно как и ядро, не решают проблему наполнения пула > >>> качественной энтропией на ранней стадии загрузки > >> Что любопытно, ядро эту задачу прекрасно решает. Особенно если > >> его об этом грамотно попросить. > > Если имеется ввиду |rng_core.default_quality=1000| , это тоже > > не совсем доверенный источник, > > Нет - я про дисковые и сетевые контроллеры. > > Для первых существует специальная функция add_disk_randomness(), > а вторые вызывают срабатывание add_interrupt_randomness() через > handle_irq_event_percpu() > > > да и про |CONFIG_RANDOM_TRUST_CPU=y| некоторые скажут, что > > эту хрень не надо никогда использовать. > > Использовать ее можно, но при соблюдении двух простых условий: > 1. должны быть и другие источники энтропии; Вот их нет. Совсем! > 2. к моменту начала использования недоверенного RNG пул должен > быть заполнен данными из других источников. Вот он ещё не заполнен. Почти... а уже надо! > И хорошо бы, чтобы > продолжал хотя бы чучуть пополняться из них. > После этого можно хоть cat /dev/zero > /dev/random запускать - на > качество энтропии это уже не повлияет :-) Энтропия -- это не продукт алгоритмов криптостойкого хэширования с начальным состоянием, это "совершенно случайные нули и единицы". Но вывод /dev/random и getrandom(), как я сейчас понимаю, это не чистая энтропия, а всё же переработанная, хотяи с заданными пороговыми значениями, чтобы число бит на выходе не было меньше реальной энтропии на входе. Если же такое качество не требуется, достаточно брать случайные числа из /dev/urandom, только вот с недавних пор лишь после инициализации начального состояния. > >>> остаётся два варианта: использовать дополнительный аппаратный > >>> (доверенный) источник > >> Разве что на компутерах, где живет какой-нибудь CA... для > >> всего остального хватает грамотно собранного ядра (которое > >> накапливает энтропию начиная уже где-то с третьей секунды > >> работы и к запуску init успевает наполнить пул). > > Так в том и проблема, что есть железо, где не успевает. > > Полностью детерминированное железо? Где? Хочу! > Продам - стану миллиардером. Один такой ТОНК отправлен в Обнинск. Вообще подверженное проблеме железо периодически всплывает. Можем завести тему в ответ на данный запрос -- список с наименованиями конкретных железок будет полезен многим. > > Только о нём спич. И здесь речь о случайных числах для запуска > > самого systemd, который может стартануть и быстрее, чем через > > три секунды. > > Он при всем желании не может стартануть раньше, чем ядро скажет > run_init_process("/sbin/init"); Процессы инициализации ядра и запуска /sbin/init асинхронны. Единственное, что делается ДО -- инициализация devtmpfs. К моменту запуска /sbin/init может быть даже не загружено ещё никаких модулей. Процесс асинхронной инициализации хорошо виден в dmesg и journalctl. У нас, правда, тут не systemd сейчас стартует, а другой /sbin/init. Но надо понимать, что прохождение stage1 зависит от железа и конфигурации системы. К моменту stage2, где в качестве /sbin/init будет уже systemd, загрузка модулей продолжится, службы же начнут запускаться по-новой. > А к этому времени пул энтропии уже должен быть хотя бы не пустым. > И достигается это (внезапно!) грамотной настройкой ядра. Осталось лишь огласить способ "грамотной настройки". > >>> ЛИБО ослаблять энтропию программными демонами типа rngd/haveged/etc. > >> А вот эту срань вообще использовать нельзя. Нигде и никогда. > > Здесь, насколько я понимаю, возражений нет? А что делать тем, кому "аппаратный" вариант недоступен? Блокировку на этапе загрузки можно рассматривать не только как баг юзабилити. В ряде задач это тоже CVE, вплоть до DoS для всего HA-кластера. В конце концов, подкопив энтропии, можно обновить состояние инициализации CRNG. А терпеть тормоза при загрузке можно далеко не во всех сценариях. -- Best regards, Leonid Krivoshein.