Linux 之父炮轟 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」有什麼壞處。即使它將來能用，也會有其他替代方案，不會比現在更糟。