因为在 Ryzen 系统上对内核造成了困扰，Linus Torvalds 最近在邮件列表中表达了对 AMD fTPM 硬件随机数生成器的不满，并提出了禁用该功能的建议。
据悉，AMD fTPM 的随机数生成器近期引起了一些卡顿问题，最初影响的是 Windows 用户，后续又波及到了 Linux 用户。虽然针对此问题的修复已经推出并回溯至早期内核，但一些与 AMD fTPM RNG 相关的棘手问题仍未解决，部分用户依然报告存在卡顿现象。
上周又有一份新的错误报告称，在某些 AMD 平台上使用 fTPM 可能会导致卡顿。此报告中其使用的 fTPM 固件版本是 0x3005700020005，这也是 Rembrand 平台首次出现此类情况；现有的内核补丁并未起到帮助作用。
这不免引起了 Linus Torvalds 的愤怒，他在邮件列表中表示：
让我们禁用愚蠢的 fTPM hwrnd。
也许在启动时使用它来“从不同的源收集熵”，但显然它不应该在运行时使用。
为什么有人要使用这个破玩意儿，因为任何一台据说修复了这个问题的机器（事实显然并非如此），其 CPU rdrand 指令也不会出现问题？
如果你不信任 CPU rdrand 实现（它也有漏洞 - 参见 clear_rdrand_cpuid_bit() 和 x86_init_rdrand()），为什么要信任引起更多问题的 fTPM 版本？所以我看不到说“那个fTPM东西不起作用”的任何缺点。即使它最终能够工作，也有一些不比它差的替代品。
因此，我不认为直接说"that fTPM thing is not working"有什么不好。即使它将来能用，也有其他替代方案，不会比现在更糟。
并补充道：
因此，[使用 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 问题。