Linus Torvalds 怒斥 Intel IBRS 补丁：纯属垃圾，硬件设计由白痴主导

Intel 的 IBRS 间接分支预测漏洞补丁设计拙劣，Linus 认为其掩盖产品缺陷、性能开销巨大且缺乏技术合理性，是典型的工程师被法务绑架的产物。

背景：Meltdown 与 Spectre 余波中的内核补丁大战

2018 年初，Meltdown（熔断）和 Spectre（幽灵）两个 CPU 侧信道漏洞被公开，业界一片混乱。Linux 内核社区在 Linus Torvalds 的领导下，紧急与各大 CPU 厂商协作，寻找缓解措施。其中，针对 Spectre 变体 2（分支目标注入，BTI），Intel 提出了一套名为 IBRS（Indirect Branch Restricted Speculation）的硬件缓解方案，并配合内核补丁进行部署。

本文是 Linus 在 Linux 内核邮件列表（LKML）上对 David Woodhouse（Intel 工程师，当时积极参与内核安全补丁开发）的一封回信。Woodhouse 在为 Intel 的 IBRS 补丁集辩护，认为这是面对"世界着火"时不得已的权宜之计。但这封回信点燃了 Torvalds 的怒火，他直言这些补丁是"complete garbage"（彻底的垃圾），并尖锐地批评了 Intel 在硬件设计层面的短视和愚蠢。

核心论战：为什么 Linus 认为 IBRS 补丁是垃圾？

1. 对"权宜之计"说法的强烈反驳

Woodhouse 在邮件中辩称：

"如果替代方案是长达二十年的产品召回，并给所有人免费 CPU，那这不完全是疯了。"
"这确实是一个令人不快的 hack，但世界着火了，我们不必关掉数据中心，回家养山羊，这还不算太糟糕。"

Linus 毫不留情地回应：

"你已经被迷魂汤灌晕了。请加入一剂健康的批判性思维。因为这不是那种让你快乐旅行、看到美丽画面的迷魂汤。这是那类会让你的大脑融化的东西。"

他明确驳斥了"这是一个丑恶但必要的 hack"的观点：

"问题不在于它是一个丑恶的 hack。它比那糟糕得多。"

2. 关键分歧：IBRS_ALL 特征位暴露了 Intel 的真实意图

Woodhouse 提到一个奇怪的特性：未来 CPU 会通过 cpuid 暴露一个 IBRS_ALL 位，表示"我能够不坏"，但为了让它"不坏"，操作系统还需要在启动时设置一次 IBRS 位来"请求"它。Woodhouse 认为这很奇怪，因为按理说这个特性和之前 Meltdown 修复的 RDCL_NO 位一样，只需表明"你不用担心了，它已经好了"即可。

Linus 指出，这正是问题的核心，比"奇怪"更严重：

"IBRS_ALL 这个特性，在我看来非常清楚地表明：Intel 并不打算认真修复这个问题。他们会搞出一个丑陋的 hack，而这个 hack 的代价（性能损失）如此高昂，以至于他们默认不想启用它，因为那会在基准测试中很难看。因此他们试图把这堆垃圾推给我们。"

Linus 进一步尖锐地分析了两种特性位的差异：

• RDCL_NO：代表 Intel 计划的修复，意味着未来产品将不再受 Meltdown 影响。
• IBRS_ALL：代表 Intel 不打算真正修复间接分支预测的问题，只提供一个性能开销巨大、本质上仍是"缓解措施"的开关让软件去承担。

"如果 Intel 真的在解决这个问题，为什么这个特性位不是像 RDCL_NO 一样直接告诉你'修复了'？"他反问。答案很明显：Intel 不愿意真正承担修复硬件的代价，而是把成本转嫁给操作系统和软件堆栈。

3. 技术层面：IBRS 补丁的逻辑荒谬

Linus 特别批评了 Woodhouse 和 Intel 提出的补丁本身。那些补丁试图在内核入口/出口点（entry/exit）增加对 IBRS 寄存器的 MSR（模型特定寄存器）写入操作。

Linus 一针见血地指出：

"你看过你正在谈论的那些补丁吗？你应该看过的——其中几个还挂着你的名字。那些补丁做了类似在系统调用入口/出口处增加那堆垃圾 MSR 写入操作的事情。这是疯狂的。这等于在说'我们试图保护内核'。而我们在那里已经有了 retpoline，并且开销更小。"

技术解释：retpoline 是一种纯软件缓解技术，通过替换间接跳转指令来避免预测器被污染。它在内核中已被广泛应用，且性能开销远比强制刷新 BTB（分支目标缓冲器）要小得多。IBRS 补丁做的事情，是在每次进入内核时强制设置一个全局开关，这会溢出所有推测性执行机制，带来巨大的性能损失（在某些测试中可达 30-50% 甚至更高）。

Linus 愤怒地得出结论：

"有人在这里没有说真话。有人出于不清楚的原因在推动完全垃圾的补丁。"

"如果是关于在真正上下文切换（切换到不同用户）时刷新 BTB，我会相信你的需求。但补丁根本不是那么做的。事实上，这些补丁是彻头彻尾、毫无疑问的垃圾。它们在做一些字面意义上疯狂的操作，做完全没有意义的事情。"

4. 对硬件接口设计的致命批判："由白痴误设计"

Linus 的批判并不仅限于驱动补丁层，更直达 Intel 的芯片设计层。他写道：

"事实是，整个硬件接口的设计就是字面意义上被白痴设计的。它有两个严重缺陷：

1. 该接口暗示 Intel 永远不会修复这个问题（看 IBRS_ALL vs RDCL_NO 的区别）。
2. 没有性能指示器。cpuid 和微架构标志位的意义在于，我们可以依赖它们来做决策。但是，既然我们早已知道 IBRS 在现存硬件上的开销是巨大的，这些硬件能力位就变得完全无用且彻底垃圾。没有任何一个清醒的人会去使用它们，因为代价实在是太高了。最终你还是不得不去看"这是哪个 CPU 步进"才能决定采取什么行动。"

Linus 的核心论点在于：

1. 设计哲学矛盾——一个真正想要修复问题的厂商，会用简单的"硬件已修复"标志（RDCL_NO）来让软件停止担忧；而 IBRS_ALL 的存在，则传达了一种"我们提供了一个昂贵得无法使用的选项，软件你看着办吧"的态度。
2. 信息不透明——没有告诉软件这个功能开启后的性能成本是多少。正常的硬件能力位（如 SSE、AVX）应该附带可预期的性能收益与权衡，而 IBRS 在几乎所有场景下都是净损失，根本没有任何积极理由去启用它，除非你是为了应付法律合规。
3. 技术倒退——正确的缓解方式应该是刷新 BTB 或隔离地址空间（像 AMD 的做法），而不是强制全局禁止预测。后者相当于在系统关键路径上加入一个巨大的同步屏障，这是对性能的彻底漠视。

结论：Linus 的最终立场

Linus 在信末总结道：

"我们必须摆脱这种为了法律上的'做做样子'（go through motions）而推进的坏技术。我不关心律师怎么想，法律理由不会成就好技术，也不会让我去应用这些补丁。"

深层反思

这篇邮件之所以在当年成为 HN 爆帖（1854 点，656 评论），不仅因为 Linus 标志性的尖刻言辞，更因为它触动了技术社区对于"安全与性能权衡"及"供应商责任"的敏感神经。

事后看来，Linus 的批评有其合理之处。Intel 在后续几代 CPU 中（如 Ice Lake）确实通过硬件形式（IBRS 改进，在硬件层面做得更快）缓解了问题，而当时社区最终也依赖 retpoline + 选择性刷新，而并未使用早期那套一刀切的 IBRS 全局开关方案，因为性能开销无法接受。Linus 提前看到了"软件背锅"的陷阱，他的愤怒源于对技术本能的捍卫——你无法用一个比自己要解决的问题更慢的方案去"解决"它。

这段历史值得我们记住，每当大型芯片厂商在硬件缺陷面前试图用软件补丁来掩盖时——开发者都应当像 Linus 一样，大声质问："WHAT THE F*CK IS GOING ON?"

原文链接：http://lkml.iu.edu/hypermail/linux/kernel/1801.2/04628.html