针对 英特尔 芯片中严重硬件缺陷的应对工作正在进行中。Nadav Amit 发布了一个补丁，以改进兼容模式对英特尔 熔断 缺陷的兼容性。兼容模式是指系统模拟旧 CPU，以便提供一个运行时环境，支持依赖于该 CPU 功能的旧软件。需要避免的是模拟旧芯片中硬件缺陷造成的大规模安全漏洞。

在这种情况下，Linux 已经通过使用 PTI (页表隔离) 免受熔断漏洞的攻击，PTI 补丁已纳入 Linux 4.15，并随后被广泛地反向移植。然而，就像旧时代的 BKL (大内核锁) 一样，PTI 是一种重量级的解决方案，对系统速度有很大影响。任何在不重新引入安全漏洞的情况下禁用它的机会都值得探索。

Nadav 的补丁正是尝试做到这一点。目标是“只要 x86-32 进程正在运行，就选择性地禁用 PTI，并在整个过程中启用全局页。”

Nadav 承认的一个问题是，由于如此多的开发人员都在积极致力于反熔断和反 幽灵 补丁，因此很有可能出现一个补丁覆盖另一个补丁尝试做的事情。因此，他说，“这些补丁被标记为 RFC，因为它们（特别是最后一个）与 Dave Hansen 启用的全局页不共存，并且可能与 Joerg 在 32 位方面的工作发生冲突。”

Andrew Cooper 令人不寒而栗地评论道

32 位本身就足以防御熔断（只要内核映射中没有任何有趣的东西低于 4G 边界）。然而，32 位兼容性进程可能会尝试使用幽灵/SP2 进行攻击，以将推测重定向回用户空间，此时（如果成功）流水线将在 64 位模式下推测，熔断漏洞又将重新出现。SMEP 将阻止这种攻击媒介，而无需考虑内核可能采用的其他 SP2 防御措施，但在完全 SP2 防御的内核中，在这种情况下不需要 SMEP 也是安全的。

附近的 Dave 评论道，“无论熔断/幽灵如何，SMEP 都是有价值的。它对所有事物都有价值，无论是否是兼容模式。”

SMEP (Supervisor Mode Execution Protection，Supervisor 模式执行保护) 是一种硬件模式，操作系统可以通过它在兼容的 CPU 上设置一个寄存器来阻止用户空间代码运行。只有已经具有 root 权限的代码才能在 SMEP 激活时运行。

Andy Lutomirski 表示他不喜欢 Nadav 的补丁，因为他说该补丁区分了“兼容模式”任务和“非兼容模式”任务。Andy 说不应该进行这种区分，特别是因为实际上不清楚如何进行这种区分，并且因为出错的后果可能是暴露重大的安全漏洞。

Andy 认为更好的解决方案是根据需要显式地启用和禁用 32 位模式和 64 位模式，而不是猜测什么是或可能不是兼容模式。

Andy 说，这种方法的缺点是，旧软件需要升级才能利用它，而使用 Nadav 的方法，判断将自动进行，并且不需要更新旧代码。

Linus Torvalds 对这些想法都不乐观。他说，“我只是觉得这一切都是一场噩梦。我可以看到你为什么会认为兼容模式不需要 PTI，但与此同时，感觉这样做是一个非常冒险的举动。” 他补充说，“我没有看到你如何阻止用户模式仅通过远跳转就从兼容模式变为 L 模式。”

换句话说，整个补丁以及任何替代方案，可能只是一个糟糕的主意。

Nadav 回复说，在他的补丁中，他试图涵盖所有可能有人试图突破兼容模式并重新启用 PTI 保护的情况（如果发生这种情况）。尽管他也承认，“我确实没有涵盖一个角落案例 (LAR)，并且 Andy 觉得这个方案太复杂了。不幸的是，我没有更好的方案。”

Linus 评论道

当然，我可以看到它在工作，但它是一些非常可疑的东西，现在调度器需要保存/恢复/检查一个更微妙的位。

如果你搞错了，事情会很高兴地工作，只是你现在已经击败了 PTI。但你永远不会注意到，因为你不会对其进行测试，唯一会测试它的人是黑帽。

这正是“安全取决于它是否同步”的事情，这让我对整个模型感到“eww”。搞错一件事，你就会把所有的 PTI 代码都搞砸。

所以现在你试图优化大多数人不会使用的一个小案例，但缺点是你可能会使我们所有的 PTI 工作（以及所有 _正常_ 情况下的开销）变得毫无意义。

Andy 还评论说，“还有一件事，如果这些东西被采纳，我们将鼓励人们部署 32 位二进制文件。然后他们会购买修复了熔断漏洞的 CPU（或 AMD CPU！），他们很可能会继续运行 32 位二进制文件。唉。我不太喜欢这样。”

整个讨论线程没有得出结论就结束了，Nadav 不确定大家是否想要他的补丁的新版本。

底线似乎是 Linux 目前已经保护了自己免受英特尔硬件缺陷的攻击，但代价是效率可能降低 5% 到 30%（实际数字取决于你如何使用你的系统）。尽管这将是复杂而痛苦的，但有非常强烈的动机通过添加更微妙和更复杂的工作方案来提高效率，从而避免 PTI 补丁的笨重方法。最终，Linux 肯定会开发出一种流畅、接近最佳的熔断和幽灵漏洞应对方法，并可能完全取消 PTI，就像过去取消 BKL 一样。在此之前，我们将面临一些非常难看且有争议的补丁。

注意：如果您在上面被提及并希望在评论区上方发布回复，请将您的回复文本发送至 ljeditor@linuxjournal.com。