導讀	因為在 Ryzen 系統上對內核造成了困擾，Linus Torvalds 最近在郵件列表中表達了對 AMD fTPM 硬件隨機數生成器的不滿，并提出了禁用該功能的建議。

因為在 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 問題。

?