Кстати, у интела оно интересно устроено. Исходя из вики, они сначала берут сырой поток данных с тепловых датчиков, формируют из них пары по 256 бит и прогоняют через AES. В итоге имеем один монолитный кирпичик 256 бит отменной энтропии, что используется в качестве сида для ГПСЧ (NIST-certified, вся хуйня; правда, называют они его DRNG - digital random number generator). Каждые ~64 килобайта генератор ресидится.

Рядом ещё есть RDSEED, оно использует всё те же тепловые флуктуации, только работает асинхронно (отдельно от основного чипа) с собственной фиксированной тактовой частотой 3ГГц. Медленнее, чем RDRAND, предназначен так же, как и назван - чтобы софтварные ГПСЧ сидить случайными числами произвольной ширины. Что, по всей видимости, и есть ключевая разница от RDRAND, который годится приложениям, которым нужен просто качественный рандом фиксированной ширины.

Правда, состояние генератора они держут общим между всеми ядрами. Ну, то есть, лежит общий некий стейджинг буфер, из которого любой может спокойно читать. И в 2020 году мужики из амстердамского университета показали, что с первой попытки можно целый ECDSA ключ сразу после подписи извлечь, если с соседнего ядра вовремя тот самый буфер почитать. А это - классическая проблема с исполнением недоверенного кода, когда он может что-то пиздить у доверенного соседа. Выпустили заплатку микрокодом, теперь RDRAND, RDSEED, EGETKEY (кто?) выполняются исключительно одним ядром за раз, остальные ждут. Просто по завершению тот стейджинг буфер перезаписывается. Задели целый ряд процов с 2012 по 2019 годы, а фикс, по классике, вкурвил и без того низкий перф (софтварные ГПСЧ кратно быстрее, что удивительно; Mersenne-Twister так и вовсе во все 20 раз).

А ещё Теодор Тсо (тот, который умнее тебя и всей твоей семьи вместе взятой) высказывал сомнения по поводу этой штуки. Мол, интеловцы хотели в ядре продавить свой RDRAND как единственный источник для /dev/random. Что, естественно, а) небезопасно (в том числе благодаря прецедентам с AMD выше) и б) просто стрёмно. Ну, то есть, мы сейчас возьмём и пересадим почти весь серверный сегмент на рандом из впаянного чипа, который никто не знает, как работает, никто не может провести аудит, так он сам ещё и от около-государственной корпорации? Звучит надёжно, наливайте!

Ну, то есть, он используется, как один из источников. Но в 2013 оказалось, что всё сыпется, если туда оказывается посажен бэкдор, нацеленный на конкретный код (маловероятная ситуация, не так ли?). Проблему смягчили (вероятно, снизили общую долю в пуле или подкрутили ϵ, чтобы оттуда более униформные значения лезли; позже и об этом пост будет). Во FreeBSD инструкцию вообще от греха подальше вырезали.


В общем, очередное напоминание, что рандом - это сложно и ответственно, а блэкбоксы - плохо. AMD не хватает побольше тестирования.