一位汇编开发者在社区发帖称，自己在测试 16 位图表应用时发现 AMD 处理器的硬件随机数指令永远摇不出数值 0，而在 Intel 芯片上一切正常。
这个听起来颇具戏剧性的指控，很快在底层开发圈引发了一场小范围狂欢。有人戏谑是否有管理者觉得“零不算随机数”从而让工程师一刀切掉，也有人立刻重申对硬件加速密码学的根本怀疑。然而扒开真实的微码勘误与系统级实现，事实呈现出了截然不同的反转。
勘误手册里的真相：缺席的零与致命的假零
在论坛的原始讨论中，开发者怀疑问题出在手头的 Zen 2 架构处理器上。但翻阅针对 Zen 2 架构的 AMD 官方勘误手册 56323（涵盖 Family 17h Models 30h–3Fh），并未包含任何关于 16 位 RDRAND 或 RDSEED 无法产出 0 的公开硬件勘误记录。
Zen 2 在历史上确实栽过随机数的跟头，但那场事故的表现形式完全不同。在早期的 AGESA 固件版本中，Zen 2 上的 RDRAND 指令会在熵耗尽等特定条件下持续返回全 1（即 0xffff、0xffffffff），并且错误地将进位标志位标示为成功。这一失误直接导致依赖硬件熵源的 Linux 启动守护进程 systemd 以及部分 C++ 基础库（如 Boost.Log）陷入无限假死。那是硬件返回全 1引发的系统灾难，而不是所谓的过滤数值 0。
更耐人寻味的是，AMD 官方真正立项并公开承认的 0 值缺陷，其实出现在代号较新的 Zen 5 架构上。
根据 AMD 官方安全公告 AMD-SB-7055 披露的 CVE-2025-62626 漏洞，Zen 5 处理器在执行 16 位和 32 位的 RDSEED 指令时，真正的危险在于其在错误生成 0 时，居然错误地将代表成功的进位标志 CF 设为了 1。换言之，硬件并非摇不出 0，而是在随机生成失败时把无效的 0 当成了真随机数硬塞给操作系统。
AMD 给出的临时缓解方案也极为直白：软件层全面改用 64 位 RDSEED、直接在 CPUID 中屏蔽 RDSEED 特性，或者由上层软件强制把返回值 0 判定为失败并进行重试。
密码学黑盒中最凶险的漏洞，往往不是不吐数据，而是把确定性的残次品伪装成随机数交付。
幽灵来自硅片还是代码：经典软件误判
既然硬件勘误表里没有“Zen 2 绝不产 0”的说法，那么测试中缺失的 0 究竟去了哪里？
在 16 位无符号整数空间中，数值 0 出现的理论概率是 1/65536。如果在采样周期内样本池不够大，统计学上的波动本身就会造成特定数值的暂时缺席。但这还不是最常见的元凶，真正的幽灵往往藏在软件抽象层对状态标志的处理里。
x86 架构执行 RDRAND 和 RDSEED 指令时，核心逻辑由进位标志 CF 掌控。CF 等于 1 代表熵源充足且随机数有效，CF 等于 0 则代表硬件熵池枯竭、生成失败，此时寄存器内保留的数值完全不可信。
在底层软件史上，混淆返回值与状态位的案例并不罕见。OpenSSL 就曾在 issue #5340 中记录过一个著名的软件侧缺陷：其封装层曾一度错误地把硬件指令返回的合法数值 0 当成了失败信号，进而触发内部重试计数器将该数值替换。原本符合正态统计的均匀随机分布，硬生生被外层软件的人工过滤切出了一个缺口。
当开发者使用手写汇编或特定宏库封装调用时，如果未严格分离进位标志判定与寄存器传值，或者在寄存器截断时引入了隐式条件跳转，合法生成的 0 就会在统计图表中凭空消失。
- 风险.将底层状态标志与数据内容混为一谈，是加密库与底层驱动中最隐蔽但也最致命的逻辑陷阱。
永远不要把鸡蛋放在 CPU 的黑盒里
这场由一条论坛帖子引发的争论，再次折射出基础软件界对硬件熵源根深蒂固的戒心。
硬件加速的随机数发生器在宣传中往往被赋予热噪声、量子涨落等高深物理光环。但在操作系统和密码学专家的眼里，只要随机数发生在硅片内部的微码管线里，它本质上就是一个无法被运行时直接审查的黑盒。
正因如此，Linux 内核在 arch/x86/kernel/cpu/rdrand.c 中早早就布设了严密的自检与降级逻辑。操作系统内核在初始化阶段会对处理器的随机数指令做严格的合规性校验。一旦检测到不可信的微码实现、未打补丁的特定已知缺陷型号，内核会直接拔掉硬件支持，降级使用操作系统自身的软件熵池。
不仅如此，现代安全体系早已形成了一条防御共识：硬件指令产出的随机数据，绝不能拿来作为纯粹的独立熵源。不管是 Linux 内核的 /dev/urandom 还是主流密码学框架，RDRAND 和 RDSEED 充其量只是多路混合器中的一路配料。它们必须与中断抖动、磁盘读写延迟以及操作系统的软件伪随机数生成器深度混合搅碎，才能最终交付给应用层。
- 建议.构建安全基础设施时，应坚持硬件指令只混熵、不独占，在架构层消除对单点硬件实现的盲信。
天下无完器。从 Zen 2 的全 1 死循环，到 Zen 5 的 CVE-2025-62626 伪 0 危机，芯片层面的设计瑕疵从未停止发生。但面对随机性异常时，与其轻易诉诸厂商删去了零的阴谋论，不如先厘清硬件标志位的严谨语义与软件防御的边界。