В новых процессорах AMD на архитектуре Zen 5 обнаружен сбой в работе аппаратной инструкции RDSEED, предназначенной для генерации случайных чисел. Согласно результатам тестирования, проведённого инженером из компании Meta, при выполнении этой инструкции в 10% случаев возвращается значение 0, при этом операция помечается как успешно завершённая (флаг CF=1). Это противоречит спецификации, поскольку ноль может также означать, что генератор не смог предоставить корректное значение, но в таких ситуациях флаг CF должен быть сброшен (CF=0). Таким образом, возникает риск интерпретации некорректного результата как допустимого.
Ошибка была впервые замечена на серверных процессорах AMD EPYC Turin, относящихся к архитектуре Zen 5, однако позднее её удалось воспроизвести и на других моделях с той же архитектурой. Это позволило сделать вывод о системной природе проблемы, что вызвало обеспокоенность у разработчиков ядра Linux. Инструкция RDSEED используется в Linux как один из источников энтропии при генерации псевдослучайных чисел, необходимых для криптографических операций и других задач, требующих высокой степени случайности.
К счастью, Linux не полагается исключительно на RDSEED — система использует комплексный подход, комбинируя данные с различных источников, включая RDRAND, состояния ввода-вывода, таймеры и другие аппаратные события. Таким образом, даже при наличии сбоя в RDSEED, общее качество случайных чисел остаётся на приемлемом уровне. Тем не менее, для минимизации рисков был подготовлен патч, который полностью отключает использование RDSEED на всех процессорах семейства AMD Zen 5.
Изначально разработчики рассматривали вариант избирательной блокировки — только для EPYC Turin. Однако после подтверждения проблемы на других процессорах Zen 5, было решено отказаться от RDSEED на всей линейке. Такой шаг считается наиболее надёжным в условиях, когда невозможно точно предсказать, на каких моделях и в каких сценариях ошибка может проявиться.
Любопытно, что выявление данного бага произошло во время изучения другой аномалии, связанной с RDSEED в процессорах AMD Zen 2. Тогда инструкция неожиданно возвращала только значение 0xFFFFFFFF. Это стало ещё одним примером того, насколько важно тщательно тестировать аппаратные функции, особенно те, что используются в криптографических и системных задачах.
Стоит отметить, что ранее в процессорах AMD уже фиксировались проблемы с инструкцией RDRAND — аналогичной по назначению, но отличающейся по внутренней реализации. В частности, были случаи, когда после выхода из спящего режима инструкция переставала работать корректно. Подобные инциденты подрывают доверие к аппаратным генераторам случайных чисел и заставляют системных разработчиков полагаться на более надёжные механизмы.
Многие специалисты по безопасности указывают на то, что использование только одного источника энтропии — плохая практика. Даже в идеальных условиях, аппаратные генераторы могут давать сбои или быть подвержены атакам. Поэтому современные ОС используют гибридные схемы, включающие в себя как аппаратные, так и программные методы сбора энтропии. Это позволяет нивелировать влияние одиночных сбоев и поддерживать высокий уровень криптографической стойкости.
Некоторые разработчики предлагают альтернативный подход к решению подобных проблем — вместо полного отключения RDSEED внедрить проверку значений с последующим статистическим корректированием, например, с помощью байесовских методов. Однако такие решения требуют дополнительной вычислительной нагрузки и могут повлиять на производительность.
В контексте криптоиндустрии проблема выглядит ещё более актуальной. Если уязвимый процессор используется в генерации ключей или адресов, например, в биткоин-кошельках, то вероятность предсказуемости случайных чисел может привести к серьёзным последствиям — от компрометации приватных ключей до потери средств. Поэтому крайне важно, чтобы такие ошибки не доходили до конечных пользователей.
С практической точки зрения, разработчики софта и администраторы должны учитывать, что RDSEED, даже при корректной работе, не является единственным или лучшим источником случайности. В большинстве случаев его можно безопасно отключить, особенно если в системе доступны другие надёжные источники, такие как TPM 2.0 или аппаратные RNG от сторонних производителей.
Наконец, стоит подчеркнуть, что сама по себе генерация случайных чисел — это далеко не тривиальная задача. Многие считают, что достаточно вызвать функцию и получить надёжный результат. Однако на практике обеспечение высокого уровня энтропии требует комплексного подхода, тестирования, анализа и постоянного мониторинга поведения системы. В этом контексте сбой даже одной инструкции, вроде RDSEED, может оказаться критичным, особенно в условиях, где безопасность критически важна.
В целом, обнаружение этой уязвимости поднимает важный вопрос: насколько можно доверять аппаратным генераторам случайных чисел? И нужно ли пересматривать архитектурные решения, чтобы исключить зависимость от одного источника энтропии в системах, требующих высокой надёжности и безопасности? Ответ пока остаётся открытым, но уже сейчас ясно, что доверие к RDSEED в AMD Zen 5 серьёзно подорвано, и меры по его исключению из критически важных процессов — шаг в правильном направлении.
