🖥️ RocksDB development finds a CPU bug
摘要
这是一个关于RocksDB团队如何在日常开发中发现AMD处理器上RDSEED指令bug的故事。该bug足够严重，被分配了CVE "高危"级别。
📌 核心发现：AMD某些型号CPU的RDSEED指令在特定微架构条件下会返回0但报告"成功"，概率远高于随机预期。该问题仅影响特定CPU核心，且仅在libstdc++(GCC)环境下出现。
故事背景
大约4年前，RocksDB团队为SST文件添加了唯一标识符，目的是为不同文件系统提供稳定的标识符用于缓存。其动机是消除对OS文件系统提供唯一标识符的依赖。
团队使用了三种熵源的组合来生成高质量随机数：
- C++11的std::random_device - 应提供高质量随机数
- 各种环境参数的哈希 - 包括主机名、进程ID、线程ID、各种时间和宏
- 平台特定的UUID生成器 - 仅限Linux和Windows
发现过程
4年内测试从未失败，直到近2个月内连续失败2次。关键发现：
- 失败测试生成的唯一ID数量比预期少几十甚至上百个
- 两次失败都运行在相同类型的硬件上，尽管在完全不同的数据中心
- 通过增加线程数到接近核心数，可以快速稳定地复现问题
- 使用rdrand和/dev/urandom的std::random_device不受影响
- libc++(Clang)不受影响，仅libstdc++(GCC)受影响
根因分析
Meta同事进行了低级别调查，发现问题在于：
- 该类型处理器的RDSEED指令返回0和"成功"的频率远高于随机预期
- 但仅在某些核心上，且仅在"复杂微架构条件下可复现"
- Linux内核开发了缓解补丁来表明RDSEED在这些处理器上不可用
- AMD已承认问题并宣布计划修复
关键教训
- 测试你依赖的东西 - 单元测试揭示了硬件bug
- 为依赖添加冗余和健全性检查 - 多种熵源组合，即使一个坏掉也有备份
- 即使CPU也可能存在bug - 通常是间歇性的单个单元问题，少数是影响所有单元的bug
技术细节
团队使用了准随机(quasi-random)方法，论文发表在ACM等平台。该方法最小化了所需的熵量，使得获取每个熵单位的性能成本几乎可以忽略。
有趣的是，文章提到RocksDB开发中越来越多的精力和CPU时间用于"逻辑上冗余但存在以在腐败传播太远之前检测CPU miscalculations"的检查。
探索时间: 2026-03-24 · 来源: Lobsters