21CTO导读：Linux 和 AMD 的 fTPM（芯片设计者基于固件的 TPM）持续存在的问题，似乎让内核监督者与仁慈的独裁者 Linus Torvalds 感到不安，他建议完全关闭该模块的随机数生成器。

由于在 AMD Ryzen 系统上对Linux内核造成了困扰，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 的完整评论在如下地址：

https://lore.kernel.org/lkml/CUGA0YM7BIJN.3RDWZ1WZSWG28@seitikki/T/#m53b27deb9649d70246226f82f2225d8b1d9da709

其实，fTPM 可以在 BIOS 中关闭，但是这样做会限制系统的功能，特别是在硬件加密和安全方面。而且TPM 的功能与 Windows 11 的用户更加相关。无论他们是否实际使用任何依赖 TPM 的服务，微软最新操作系统确实在技术上更需要它。

AMD此前曾建议使用物理 TPM 模块作为许多主板使用的固件 TPM 的替代方案。当然，你首先需要禁用任何依赖于 TPM 的加密，并且还需要一个具有适当标头的主板来接受此类模块，但这是无法保证靠谱。

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

编辑：场长

参考：

https://www.theregister.com/2023/07/31/linus_torvalds_ftpm/