导读 | 因为在 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 问题。
原文来自:
本文地址://q13zd.cn/linus-torvalds-amd-ftpm-rng.html编辑:J+1,审核员:清蒸github
Linux大全:
Linux系统大全: