并补充道：

因此，[使用 RDRAND 时出现问题]听起来不太可能，但谁知道呢...... Microcode 显然可以做任何事情，至少最初的 fTPM 问题似乎是因为 BIOS 做了一些真正疯狂的事情，如 SPI 闪存访问。

我可以很容易地想象到 BIOS fTPM 代码会使用一些绝对可怕的全局“EFI synchronization”锁或其他东西，从而导致一些完全无关的随机问题。

举例来说，如果不是 fTPM hwrnd 代码本身决定从 SPI 读取某个随机数，但它只是与 BIOS 涉及的其他内容进行序列化，我也不会感到惊讶。并非所有BIOS人员都以他们完全并行的可扩展代码而闻名......

如果 CPU microcode 能做任何类似的事情，我会非常惊讶。而这也并非不可能 - 惠普公司就曾用 SMI 将时间戳计数器搞得一团糟，我可以想象他们 - 或其他人 - 也会对 rdrand 做同样的事情。

但与“EFI BIOS uses a one big lock approach”相比，这听起来确实不太可能。

因此 rdrand （尤其是 rdseed）可能相当慢，但我认为我们讨论的是数百个 CPU 周期（也许是几千个）。与我们从 fTPM 看到的卡顿报告完全不同。

 希望在 Torvalds 的额外压力下，将会有一些额外的明确性和修复方案来解决 Linux 下的 AMD fTPM 问题。