熔断和幽灵漏洞

2018年1月，熔断英特尔 quietly 推送了一个微码更新，和幽没开发布会，灵漏没发新闻稿。熔断很多运维工程师是和幽在重启服务器之后才发现性能掉了——有些数据库查询慢了将近30%。那时候大家还不知道，灵漏这个补丁背后藏着一颗炸了半个硅谷的熔断雷。

这颗雷叫“熔断”（Meltdown），和幽还有一个兄弟叫“幽灵”（Spectre）。灵漏名字起得挺酷，熔断本质却极其粗暴：它们利用现代CPU的和幽乱序执行和推测执行机制，让攻击者能从一个进程里偷看另一个进程的灵漏内存。理论上，熔断你浏览器里跑的和幽一个恶意JavaScript，可以读到隔壁密码管理器刚解密出来的灵漏主密码。这不是提权漏洞，这是直接拆了进程隔离的墙。

要理解这事有多离谱，得先知道CPU平时在干嘛。你写一行 if (x < array_len)，CPU不会傻等判断结果。它会猜——大概率x是合法的——然后提前把 array[x] 的数据加载进缓存。猜对了，皆大欢喜；猜错了，丢弃结果，架构上什么都没发生。但缓存没清。缓存是个物理存在的东西，它的状态变化会留下痕迹。攻击者通过测量缓存命中时间，就能反推出那个“被丢弃”的值。这就像你偷看别人信封里的内容，虽然信封被收回去了，但你记住了纸张的厚度和折痕。

熔断和幽灵的区别在于攻击面。熔断更直接，它利用的是CPU对权限检查的推测执行——用户态代码可以推测性地读取内核内存，虽然最终会触发异常，但缓存里已经留下了内核数据的影子。幽灵更阴险，它不违反权限检查，而是诱导合法代码（比如浏览器的JIT引擎）在推测路径上泄露自己的数据。熔断影响几乎全部英特尔芯片和部分ARM，幽灵则波及英特尔、AMD、ARM——几乎所有人。

修复方案一出来，性能就成了牺牲品。KPTI（内核页表隔离）把内核和用户态页表彻底分开，每次系统调用都要切换页表，上下文切换开销直接翻倍。云厂商最惨，因为他们的生意建立在“多租户共享同一台物理机”上。AWS、Azure、GCP紧急排期重启，客户收到邮件说“我们会在这周内打补丁，性能可能下降个位数到两位数百分比”。有工程师在Twitter上吐槽：这哪是补丁，这是给CPU戴了个N95口罩，呼吸都费劲。

更麻烦的是，幽灵没有单一补丁。它是一类攻击手法的集合，变种一个接一个：Spectre v1、v2、v4，后来还有SpectreRSB、SMoTherSpectre。每出一个变种，编译器就要加一道屏障，代码体积膨胀，性能再掉一点。Linux内核开发者一度在邮件列表里吵翻天，有人主张默认关闭某些优化，有人坚持性能优先。最后搞出来的prctl和seccomp缓解措施，普通用户根本感知不到，但云账单上的CPU使用率骗不了人。

我印象最深的是一个做高频交易的朋友。他们的策略延迟要求是微秒级，补丁一打，延迟直接多了十几微秒。他说那感觉就像博尔特跑百米，突然有人往他鞋里塞了块石头。他们最后的选择是：买更贵的、专门定制的CPU，或者把关键业务迁到不共享的裸金属上。安全从来不是免费的，只是账单寄给了不同的人。

七年过去了，熔断和幽灵没有被“修复”，它们被“缓解”了。CPU架构改了，微码更新了，操作系统加固了，但根本矛盾还在：我们想要快，CPU就得猜；CPU一猜，就可能漏。这个 trade-off 没有完美解，只有不断加码的补丁和越来越复杂的信任模型。下次你看到“性能提升20%”的芯片发布会，可以想想背后有多少幽灵在游荡。