几周以来，全世界都在谈论影响许多 CPU 的严重英特尔设计缺陷，并迫使操作系统寻找有时代价高昂的变通方法。

针对这些问题的 Linux 补丁正处于持续开发状态。安全始终是首要任务，不惜牺牲任何其他功能。其次可能是普通用户运行系统的总体速度。之后，开发人员可能会开始拼凑最初安全修复中撤回的任何功能。

但是，尽管这项工作仍在进行，内核开发人员似乎对英特尔相当生气，尤其是当他们认为英特尔在未来处理器中没有采取足够的措施来解决这些问题时。

例如，针对一组补丁，Linus Torvalds 爆发了， “所有这些都是纯粹的垃圾。英特尔真的计划让这种狗屎成为架构的一部分吗？有人和他们谈过并告诉他们他们他妈的疯了吗？” 他继续说道，“IBRS 垃圾意味着英特尔_不_打算为间接分支推测做正确的事情。老实说，这完全不可接受。” 然后他说

对我来说，整个 IBRS_ALL 功能非常清楚地表明“英特尔对此并不认真，我们将有一个丑陋的黑客攻击，它会非常昂贵，以至于我们不想默认启用它，因为这在基准测试中看起来会很糟糕”。因此，他们试图将垃圾推给我们。而且他们完全做错了。

他继续说，甚至更令人不安地说

这些补丁所做的事情就像将垃圾 MSR 写入内核入口/出口点。这太疯狂了。这表明“我们正在尝试保护内核”。我们已经有了 retpoline，开销更少。

所以有人在这里没有说实话。有人出于不明原因推送完全的垃圾。抱歉不得不指出这一点......就目前而言，这些补丁是完全彻底的垃圾......到底他妈的发生了什么？

在某个时候，David Woodhouse 为我们这些坐在前排的人提供了一个关于整个情况的有用技术总结

这一切都与 Spectre 变体 2 有关，其中 CPU 可能被欺骗，从而错误预测间接分支的目标。我特别关注我们可以在*当前*硬件上做些什么，在当前硬件上，我们仅限于他们设法在微代码中添加的 hack。

来自英特尔和 AMD 的新微代码添加了三个新功能。

一个新功能 (IBPB) 是分支预测的完整屏障。在拨动此功能后，之前学习的任何分支目标都不会被使用。它有点昂贵（数量级约为 4000 个周期）。

第二个 (STIBP) 保护超线程兄弟免受遵循在另一个兄弟上学习的分支预测的影响。例如，当在用户空间中运行不相关的进程时，您*可能*需要此功能。或者在 HT 兄弟上运行的不同 VM 访客。

第三个功能 (IBRS) 更复杂。它旨在在您进入更高级别的执行模式（即内核）时设置。它防止在最近一次设置之前，在较低权限的执行模式下学习的分支目标生效。但这不仅仅是一个“设置并忘记”的功能，它还具有类似屏障的语义，需要在*每次*进入内核时（从用户空间或 VM 访客）设置。它*也*很昂贵。这是一个邪恶的 hack，但在一段时间内，它是我们唯一的选择。

即使使用 IBRS，CPU 也无法区分不同的用户空间进程以及不同的 VM 访客。因此，除了使用 IBRS 来保护内核之外，我们还需要在上下文切换和 vmexit 时使用完整的 IBPB 屏障。也许在它们运行时需要 STIBP。

然后 Paul 提出了一个狡猾的计划，“哦，间接分支可以被利用？去他的，让我们不要有任何*那些*”，这就是 retpoline。它比在每次进入内核时拨动 IBRS 快*得多*。这是一个巨大的性能提升。

所以现在我们*主要*不需要 IBRS。我们使用 retpoline 构建，在上下文切换/vmexit 时使用 IBPB（这在添加 IBRS 之前的此补丁系列的第一部分），我们是安全的。我们甚至重构了补丁系列，将 retpoline 放在首位。

但是等等，我为什么说“主要”？好吧，并非每个人都有 retpoline 编译器...但好吧，去他们的；他们需要更新。

还有 Skylake，以及那一代 CPU 内核。由于复杂的原因，它们最终不仅在间接分支上容易受到攻击，而且在某些情况下（例如深度链中的 16+ 个 CALL）的“ret”上也会受到攻击。

虽然 IBRS 解决方案很丑陋，但它确实解决了这个问题。Retpoline 没有。正在浮出水面的补丁可以检测和防止深度堆栈，并处理 SKL 上的一些其他特殊情况，但这些也很糟糕。事实上，在这一代 CPU 上，IBRS 性能远不如早期 CPU 上的性能那么糟糕，这使得*考虑*按照英特尔的提议使用它并非完全疯狂。

这就是为什么我的最初想法，如此 RFC 补丁集中实现的那样，是在 Skylake 上坚持使用 IBRS，并在其他任何地方使用 retpoline。我会给你“垃圾补丁”，但它们并非“只是盲目地发送”。如果我们打算放弃 IBRS 支持并接受警告，那么让我们在看到它会是什么样子之后有意识地做出决定，而不是因为可怜的 Davey 太害怕 Linus 可能会再次对他大喊大叫而悄悄地放弃它。

我看到了对 Skylake 事情的*粗略*分析，这意味着我实际上并没有夜不能寐地为此烦恼，但没有任何具体的说法表明它没问题。

如果您将 retpoline 视为性能优化，这也是它最初出现的方式，那么说“好吧，它只会打开*一点点*安全漏洞，但它确实运行得很好而且很快，所以让我们这样做”是相当非传统的。

但好吧，我满足于放弃使用 IBRS 来保护内核，我什至不感到惊讶。*原因*是我们将其放在系列中的最后，既是最有争议的部分，也是最可有可无的部分。如果有一个连贯的分析表明 Skylake 仍然没问题，我会*更*高兴，但是，去他妈的 Skylake。

该系列的早期部分添加了新功能位，并检测到何时可以在非熔断漏洞的英特尔 CPU 上关闭 KPTI，并且还支持我们使 retpoline 完整所需的 IBPB 屏障。我认为我们绝对*需要*这么多。我们很多人一直在幕后为此努力；我们中的一个人可能会在接下来的一两天内发布该部分。

我认为我们还希望向 VM 访客公开 IBRS，即使我们自己不使用它。因为 Windows 访客（和 RHEL 访客；耶！）确实使用它。

如果我们能结束叫喊部分，我实际上很想就何时（如果曾经）我们在上下文切换时执行 IBPB（ptraceability 和 dumpable 都已被提出）以及何时（如果曾经）我们在用户空间中设置 STIPB 进行明智的讨论。

邮件列表上的大部分讨论都集中在寻找实际解决方案的技术问题上。但是 Linus 并不是唯一一个发现这种情况不可接受的人。包括 David 在内的各种开发人员都感到非常反感，不是因为设计缺陷本身，而是因为他们认为英特尔处理后续情况的方式——糟糕的技术修复、英特尔开发人员与内核社区之间缺乏沟通，以及正如 Linus 指出的那样，英特尔可能选择根本不解决某些问题。

注意：如果您在上面被提及，并且想在评论部分上方发布回复，请将包含您的回复文本的消息发送至 ljeditor@linuxjournal.com。