Мне трудно следовать указаниям в недавней ветке LKML о том, что делать с длительной (неограниченной?) Блокировкой вызова getrandom при инициализации системы.
Суть проблемы в том, что ядро не получает и не создает достаточно энтропии для своевременного успешного вызова getrandom.
Линус Торвальдс, для меня непостижимо, выступал за нарушение пользовательского пространства в этой теме., изменив поведение ошибки getrandom на с EINVAL.(Кто мешает Линусу нарушить пользовательское пространство?)
Возможно, именно ядро виновато в том, что недостаточно энтропии для пользовательского пространства даже в раннем пользовательском пространстве.
(void *)getauxval(AT_RANDOM) уже в процессе инициализациидает указатель на 128 бит случайности.(Библиотека AC может даже использовать ее для инициализации таких вещей, как значение __stack_chk_guard.)
Почему ядро не может принять (те?) 128биты для инициализации CSPRNG, которые будут использоваться реализациями ядра getrandom(..., 0) и /dev/urandom, позволяя этим интерфейсам выводить любое запрошенное количество псевдослучайных значений?
Очевидно, что в OpenBSD такой проблемы нет.Его arc4random_buf функция всегда возвращает запрошенную случайность без возможности ошибки.Таким образом, я предполагаю, что ядро OpenBSD всегда может получить достаточно энтропии, чтобы затем инициализировать CSPRNG либо в ядре, либо на стороне пользователя.
Какие были варианты, которые привели к тому, что в OpenBSD появилась функция без ошибок?И может ли ядро / пользовательское пространство Linux принять те или иные варианты для getrandom?