Linux之父“开炮”！曾喊AMD真香，今炮轰AMD：怒批fTPM“愚蠢”、“破玩意儿”

整理 | 郑丽媛

还记得 2020 年 5 月，Linux 之父 Linus Torvalds 宣布他 15 年来第一次抛弃英特尔，更换了一台搭载 AMD 处理器的新电脑时，给开发者们带来的震撼：

事实上，本周最让我兴奋的是我升级了我的主机，这是 15 年来第一次，我的桌面不是基于英特尔的，新电脑安裝了 AMD Threadripper 3970X 处理器后，我的 “allmodconfig” 测试构建现在比以前快了三倍。

(资料图片)

不难看出，当时 Linus 对于将电脑处理器从英特尔升级为 AMD 的决定颇为满意，同时他的兴奋也带动了不少开发者转向 AMD 阵营。

不曾想时隔三年，看似力挺 AMD 的 Linus 最近却开始对 AMD 的 fTPM 功能表达了强烈不满：“让我们禁用愚蠢的 fTPM hwrnd 吧！”

（图片来自 wccftech）

AMD fTPM 导致系统出现卡顿问题

Linus 提到的这个 fTPM 功能，相信这两年关注过 Windows11 的人应该不会陌生——就是那个被一众网友反复吐槽的硬件“高门槛”。

在微软将 “TPM 2.0” 设为 Windows11 最低硬件要求之前，可能多数人并未听说过 TPM。TPM（Trusted Platform Module，可信平台模块），是根据国际行业标准组织可信计算组规范制作的模块，可以是 dTPM 真实硬件，也可以是 fTPM 等由固件模拟的软件模块。无论是基于固件还是硬件，TPM 都用于安全创建和存储加密密钥、证书和密码等。

由于微软将 TPM 作为运行 Windows 11 的一项硬性要求，因此许多 AMD 用户开始研究主板的 BIOS 系统，以启用 fTPM 模块来运行 Windows 11 操作系统。

然而，启用了 fTPM 模块后，不少使用 AMD Ryzen 处理器的用户都表示：为什么系统总是间歇性卡顿，尤其是音频故障和游戏帧率卡顿？！

排除了用户自身问题和 Windows 11 错误后，问题答案似乎就出来了：AMD 的 fTPM 和 Windows 之间可能存在兼容性问题。果不其然，2022 年 3 月 AMD 终于查明了卡顿原因并发布公告：

“AMD 已确定，部分 AMD Ryzen™ 系统配置可能会间歇性地在主板上的 SPI 闪存（“SPIROM”）中执行与 fTPM 相关的扩展内存事务，这可能会导致系统交互性或响应性暂时中止，直至事务结束。”

引起“暴脾气” Linus 的炮轰

一般来说，当系统安全模块与 TPM 进行数据沟通时，同时系统其他部分也在访问内存，而为了保证读取/写入/修改数据时不发生冲突，提升操作性能，系统会采用一种名叫内存事务的方法。

而根据 AMD 给出的卡顿原因，其 fTPM 就是在内存事务上出问题了：只要系统安全模块与 fTPM 进行数据交换，剩下的硬件就需要等到 fTPM 的事务执行完成后才能继续使用其他内存，由此导致电脑卡顿。

发现问题后，AMD 表示公司正在研究解决方案，要到“5 月初”或更晚才会推出。后来 AMD 也确实更新了解决方法：“作为直接解决方案，依赖 fTPM 功能支持可信平台模块的受影响客户可以使用硬件 TPM（“dTPM”）设备进行可信计算。”

起初，卡顿问题仅限于 Windows 平台，即 Ryzen 处理器在启用 fTPM 后会导致 Win10、Win11 系统出现间歇性卡顿。因此当 AMD 发布了解决方案后，Windows 平台上的卡顿问题就得到了很大程度的改善。

但后来，Linux 发行版本也受到了影响，甚至情况还要糟糕得多，不仅会出现卡顿，还会导致更严重的编译错误。即使有修复程序也没有彻底解决这个问题，在 Linux 6.1 内核表现最为明显，主要是在硬件随机数生成器（hwrng）为不受信任的源启用内核多线程（kthread）之后触发。

对于这个情况，AMD 却没给出更多有效的应对方案——时间一长，意料之中地引起了向来“暴脾气”的 Linus 的“炮轰”。

“我不认为直接禁用 fTPM 有什么坏处”

截至目前，AMD 并没有对 fTPM 在 Linux 上引发的问题做出明确解释，而 Linus 做出了一番推理：“我可以很容易地猜出 BIOS fTPM 代码应该使用了一些可怕的全局 EFI 同步锁之类的东西，然后就会根据一些完全不相关的活动引发随机问题。举例来说，可能不是 fTPM hwrnd 代码本身决定从 SPI 读取某个随机数，而是它与 BIOS 参与的其他活动串行化。”

在 Linus 看来，解决这个问题的方法很简单：既然 fTPM 带来了这么多问题，那为什么不禁用 fTPM hwrnd，去采用处理器的 rdrand 指令来提供随机数呢？

让我们禁用愚蠢的 fTPM hwrnd 吧！也许可以在启动时用它来"从不同来源收集熵"，但显然不应该在运行时使用。

既然任何一台据称已修复这个问题的机器（事实显然并非如此），其 CPU rdrand 指令不会出现这个问题时，为什么有人要用这个破玩意儿？如果你不相信 CPU 的 rdrand 实现，那为什么还要相信引发了更多问题的 fTPM 呢？

因此，我不认为直接“禁用 fTPM”有什么坏处。即使它将来能用，也会有其他替代方案，不会比现在更糟。

简单来说，Linus 认为 fTPM 最多只能在系统启动时，用于为内核的随机数生成服务提供熵，但在系统正常使用过程中，fTPM 不能用作随机数源。

此外，Linus 也承认 rdrand 可能会很慢，但与目前 fTPM 造成的卡顿相比，rdrand 似乎是更好的替代方案：“rdrand 可能会相当慢，但我认为我们说的是几百个 CPU 周期，这与我们从 fTPM 上看到的卡顿报告要好得多。”

因此，按照 Linus 的说法，AMD 用户如在 Linux 发行版中遭遇卡顿，在 BIOS 中禁用 fTPM 或许是当前最好的解决方法。但实际上，这样也会限制系统功能，尤其是在硬件加密和安全方面。

不过考虑到 Linus 在业界的强大影响力，他的这番“炮轰”或许也会促使 AMD 对此引起重视，从而尽快想出合理有效的方案。

标签：