LWN：RDRAND的后续进展！

关注了就能看到更多这么棒的文章哦～

A RDRAND followup

By Jonathan Corbet
February 26, 2024
Zhipu translation
https://lwn.net/Articles/963281/

在最近的一篇文章《Pitchforks for RDSEED》中，我们了解到关于 x86 CPU 上的基于硬件的随机数生成器是否可能失败，是存在一些不确定性的。由于在某些情况下（具体是机密计算应用）出现失败的影响可能是灾难性的，因此人们对这一前景及其应对措施感到担忧。自那时起，情况变得更加明朗，人们似乎已经达成了共识，要在内核中进行更改。

在上篇文章的最后，提到 CPU 供应商之间仍在讨论 RDRAND 和 RDSEED 指令是否可能无法生成真正的随机数。毕竟，如果没有对硬件有一个彻底的了解的话，很可能会获得错误的随机结果。2 月 14 日，Elena Reshetova 总结了英特尔在这个问题上的立场：

无故障的设备上的 RdRand 从设计上确定比总线更快，因此当 core 访问 DRNG 的输出时，它总会得到一个随机数。因此，很难想象一个完全正常工作的设备的 RdRand 会下溢（underflow）。

换句话说，=RDRAND= 总是可以预期会成功的。而更底层的 RDSEED 指令则更直接地消耗熵，正如讨论参与者已经展示的那样，在压力过大的情况下会失败。

机密计算应用的安全模型核心需要的是不受主机系统（或任何人）控制的真实随机数据。只有内置在 CPU 本身的随机数生成器才能满足这一要求；其他任何东西都可能受到外部操纵。然而，有一个普遍的共识，即来自 RDRAND 的数据即使对于机密计算也是足够好的，因此没有必要使用 RDSEED 。因此，这些应用应该在英特尔系统上是安全的—至少在随机数泄露这个方面。

内核随机数生成器的维护者 Jason Donenfeld 回应了一系列简短的 patch，做了一些更改。一个是如果尝试使用 RDRAND 失败，立即给出 warning，这是按照上述假设，任何这样的失败都指示了一个硬件问题。该补丁还删除了循环，原本的循环会尝试操作十次，因为即使一次失败也表明硬件已经损坏，重试也不太可能解决问题。然而，这个更改有一个小问题，正如 Tom Lendacky 指出的：关于 RDRAND 的鲁棒性的说法适用于当前的 CPU。较老的处理器可能会有不同的行为，也可能有 cases 需要进行重试。因此，这个补丁目前看起来已经被放弃了。

另一个改动是在机密计算支持代码，试图在启动时间用 256 位的 RDRAND 输出来对内核的随机数生成器播种。如果尝试失败的话就会让系统立即 panic。任何此类失败都将表明机密计算虚拟机缺乏一个可靠的随机数源，因此，无法实现所需的机密性。在这种情况下，最好是立即停止，而不是以可能被泄露的方式运行。

后一个 patch 已经在稍微调整后重新发布了，并获得了几位相关开发者的 Reviewed-by 标签。所以，看来这个具体的故事的结局已经不远了—直到如往常一样有一天有人发现随机数生成器中的其他问题。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～