В /dev/random опять пытаются пропихнуть hwrng как единственный источник энтропии!

«Шо, опять?!»

В /dev/random опять пытаются пропихнуть hwrng как единственный источник энтропии!

Пытаются сделать так, чтобы на ранних этапах одного HWRNG было достаточно для наполнения пула. Это не «единственный источник».

Но есть проблема с устройствами, которые генерируют сертификаты во время первого включения. По сути, для них HWRNG будет единственным источником, потому что он один будет иметь данные сразу после загрузки.

Чем он плох?

for example embedded systems, do not generate

enough entropy on boot through interrupts, and boot may be blocked for several minutes waiting for a call to getrandom to complete.

Я и на десктопе с таким сталкиваюсь (то ли systemd, то ли logind висит в ожидании этой энтропии), по-этому приходится накатывать какой-то там пакет-костыль. Считаю что если по дефолту таких проблем не будет то это будет плюсом. Параноики могут генерировать энтропию хоть катаясь лицом по клавиатуре, не думаю что им будет сложно переопределить это базовое поведение.

Погугли срач вокруг Теодора Тсо. Он как раз недавно всплывал.

Я и на десктопе с таким сталкиваюсь (то ли systemd, то ли logind висит в ожидании этой энтропии), по-этому приходится накатывать какой-то там пакет-костыль. Считаю что если по дефолту таких проблем не будет то это будет плюсом.

Для чего конкретно в ходе загрузки нужен пул энтропии? Какие ключи при этом генерируются?

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

Чтобы что-то переопределить, надо хотя бы знать об этом. Между тем, атаки такого рода через random вполне возможны, это не просто параноя на тему, что вместо миллиарда лет всего сто миллионов придется подбирать пароль.

Сейчас предлагают ослабить безопасность, вместо того, чтобы убрать неправильное поведение systemd или чего там.

Для чего конкретно в ходе загрузки нужен пул энтропии? Какие ключи при этом генерируются?

Без понятия, но это происходит после ввода логина\пароля перед загрузкой десктопа.

предлагают ослабить безопасность

Тут, КМК, та ситуация когда надо соотносить стоимость защищаемой информации с ценой этой защиты. Я, например, не готов ждать несколько минут при загрузке, хоть и перегружаюсь я очень редко, потому что я как тот Неуловимый Джо. Кому нужно может же использовать «более рандомные» генераторы.

Гуглится только что он в 2010 предлагал пользователям активнее участвовать в разработке ядра, вкладываясь деньгами или временем.

Недавние срачи были связаны с поехавшими трапами, если так то не интересно, это не связано с технологиями же.

Без понятия, но это происходит после ввода логина\пароля перед загрузкой десктопа.

Так вот есть мнение, что это для загрузки десктопа абсолютно не нужно. И вообще не нужно, за исключением каких-то может совсем особых сценариев работы.

Тут, КМК, та ситуация когда надо соотносить стоимость защищаемой информации с ценой этой защиты.

Нет, здесь совершенно не та ситуация. Здесь на ровном месте хотят ослабить защиту, и даже не ослабить, а сделать ее фактически несуществующей, если в генераторе есть закладка.

Я, например, не готов ждать несколько минут при загрузке, хоть и перегружаюсь я очень редко, потому что я как тот Неуловимый Джо.

Так ведь и не требуется тебе ждать, ты думаешь, что это компромисс с защищенностью, а это компромисс с говнокодерством (вернее говноархитекторством).

Зачем вообще тогда на раннем этапе наполненный пул?
Там, где он таки нужен (та же генерация ключей при первом включении), HWRNG будет единственным источником => решето.

Выходит, таки почалося!

Уже видел наезды на Тсо от какой-то зеленоволосой истерички, работающей сюрприз-сюрприз в Intel. Причем, её безосновательные выпады этот самый CoC и нарушали.

Недавние срачи были связаны с поехавшими трапами, если так то не интересно, это не связано с технологиями же.

Минутка паранойи. Поехавший трап С.Шарп это, ЕМНИП, то самое чудо, которое в своё время будучи работником интела наваяло подсистему xhci для линукса и справедливо получило на голову ушат помоев за качество кода (у меня лично xhci еще год после появления работал серийным самоубийцей), после чего хлопнуло дверью со словами «вы просто мужланы-шовинисты и ненавидите всё женское».

Тео же в своё время послал нахер интел с их предложением использовать интеловский rdrand как единственный источник энтропии.

И тут наше поехавшее на зарплате от интела на следующий день после ввода CoC вываливает «компромат» на Тео (ну т.е. для нормальных людей оно «компромат», а для тоталитарных шизиков - повод расстрелять).

Исходя из паранойи 101 шиза уже начала использоваться для устранения неугодных.

А что касается недостатка энтропии при загрузке и блокировки - то уже прямщас есть RANDOM_TRUST_CPU, и у вас есть выбор, траст вы ЦПУ или нет. Причем оно одобрено Тео (именно потому, что у вас есть выбор) и вроде как рекламировалось как раз как решение проблем с недостатком энтропии при загрузке. Не знаю, чего там внутри у random.c, и зачем нужна новая хрень при наличии старой.

наваяло подсистему xhci для линукса и справедливо получило на голову ушат помоев за качество кода <...> после чего хлопнуло дверью

меня лично xhci еще год после появления работал серийным самоубийцей

Какая-то странная история. Мне не понятно почему код тогда приняли в ядро, если он работал плохо. То есть безотносительно проблем с гендерами, если разраба посылают в пешее эротическое почему его говнокод попадает на машины пользователей?!

на следующий день после ввода CoC вываливает «компромат» на Тео (ну т.е. для нормальных людей оно «компромат», а для тоталитарных шизиков - повод расстрелять)

Эм, ну если я например сейчас напишу в lkml типа там «микроядро рулит и педалит, ваше линух фуфло бай дизайн и устарел еще до его выхода» то меня в лучшем случае просто пошлют, а вообще скорее всего даже отвечать не будут. Почему тогда обращают внимание на это бурление? Персонаж же не имеет никакого отношения к разработке, ну предлагает там что-то, никто не обязан его слушать же? Факи nvidia показывали, а тут почему стушевались?

-----

использовать интеловский rdrand как единственный источник энтропии

то уже прямщас есть RANDOM_TRUST_CPU, и у вас есть выбор, траст вы ЦПУ или нет.

Я использую haveged. Вот не разбираюсь в этом, но судя по тому что я могу решить проблему установкой специального демона, который будет мне эту энтропию генерить, в ядре все это не прибито. В чем тогда проблема, почему источник должен быть один? Ну то есть в чем профит для того же интела понятно, можно напихать закладок да потом пользоваться, но с точки зрения разработки ядра почему этому уделяется столько внимания?

-----

Короче, резюме (а то жаль удалять что написал) - почему этому срачу придают значение?

Чот ты в последнее время везде этих сжв пихаешь. А не их ли агент ты часом?

а ты?

Апвовнв?

Вся соль в том, что Тсо входит в состав ключевых разработчиков Linux, а эта мразотная жируха - нет.

Зато у неё борода больше чем у Линуса!

то уже прямщас есть RANDOM_TRUST_CPU

Как включить для дебиана не ничего перекомпиляя? Отож.

Но есть проблема с устройствами, которые генерируют сертификаты во время первого включения.

Просвещения ради спрашиваю, это каким же устройствам нужно для работы генерировать сертификат, едва их включили?

Просвещения ради спрашиваю, это каким же устройствам нужно для работы генерировать сертификат, едва их включили?

Ну например при установке линукса на пустую железку надо сгенерировать сертификаты для SSH при первом включении. Однако, совершенно непонятно, нахрена это нужно делать _быстро_ жертвуя безопасностью и оставляя потенциальную дыру если железячный генератор скомпрометирован. Всё равно последующая настройка займёт на порядки больше времени и эта задержка вообще никакой заметной роли в процессе установки и настройки не сыграет.

Ну например при установке линукса на пустую железку надо сгенерировать сертификаты для SSH при первом включении.

Согласен, тут надо. Но это сильно особый сценарий работы, в конце-концов при каждой перезагрузке Linux не устанавливают. И не у каждого после установки вообще установлен ssh-доступ к нему.

Всё равно последующая настройка займёт на порядки больше времени и эта задержка вообще никакой заметной роли в процессе установки и настройки не сыграет.

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

Начиная с 4.19-rc3 - через параметр загрузки random.trust_cpu=on, но то ж дебиан, там же в стейбле поди еще и RANDOM_TRUST_CPU не завезли.

блин, вот сразу бы они сделали параметр. а то с 4.13 возились. будто издевались

ps. у меня тестинг, так что как будет опия в релизе так почти сразу