整理 | 鄭麗媛
出品 | CSDN（ID：CSDNnews）
還記得 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 對此引起重視，從而盡快想出合理有效的方案。
參考鏈接：
https://www.theregister.com/2023/07/31/linus_torvalds_ftpm/
https://lore.kernel.org/lkml/CUGA0YM7BIJN.3RDWZ1WZSWG28@seitikki/T/
https://www.amd.com/en/support/kb/faq/pa-410
