AMD RDRAND 无法生成 0 的硬件随机数缺陷
问题概述
在 AMD Zen 2 处理器上,RDRAND 指令有时只返回全 1(-1),导致依赖硬件随机数的程序在启动时崩溃;同时该指令可能无法生成 0,使得随机数不可靠,尤其在安全关键代码中。用户需要通过 XOF 或微码更新等方式进行变通。
痛点标签
- RDRAND 指令在某些 Zen 2 处理器上可能返回全 1(-1),导致依赖随机数的程序崩溃
- 该指令可能无法生成 0,使得随机数不可靠,尤其在安全关键代码中
- 需要通过 XOF 或微码更新等变通方案来弥补硬件缺陷
待验证问题
- 最新的微码或 BIOS 是否已解决 RDRAND 只返回 1 的问题?
- 用户在实际生产环境中是否仍然遇到该缺陷导致的崩溃?
- XOF 等替代方案在工业界是否被广泛采用?
证据
原话
This is not the first RNG bug on Zen 2, I recall after I first got mine that some application or other would quit immediately at startup because rdrand always returned -1, i.e. all 1s. It was fixed with a microcode update.Do we now learn that they fixed "always generate all 1s" with "never generate all 0s"??EDIT: I've been unable to reproduce the problem on my CPU, FWIW. It's a Ryzen 5 3600.EDIT2: OK, update, I can reproduce it with rdrand16, rdrand32 is fine but rdrand16 can never generate all 0s. So my CPU does have this problem!
原话
This is why I use, in security critical contents of my software (where the numbers have to be computationally infeasible to produce), a type of random number generator called an XOF (extendable-output function).It takes entropy from multiple different sources, makes it all input to the XOF, then the XOF uses cryptography to output a stream that has as much entropy as the combined entropy of all of its sources of randomness. So if an XOF, for example, takes 100 runs of rdrand16, along with the system time in microseconds and the number of milliseconds between receiving 100 packets over the network, the XOF will output a completely random stream without artifacts like never returning 0x0000, even if rdrand16 never outputs 0x0000.
原话
I remember setting up a new git CI build server many years ago, which at the time rather quickly started failing build pipelines in a nodejs css frontend build script, turns out there was something funky with the AMD processor's RDRAND. A motherboard BIOS flash update fixed it.
免责声明:本卡片由 AI 从社区讨论中提炼,属于「痛点证据」,是需求分析与验证的起点,不等同于「已验证的市场需求」。AI 存在分析局限,关键决策前请打开上方原始讨论人工复核。