现代 CPU 的速度，很大一部分来自推测执行：分支还没算出结果，处理器先猜一个方向往下执行，猜对了省下等待时间，猜错了丢弃结果重来。这套机制让流水线常年保持忙碌，也正是 2018 年初曝光的 Spectre 与 Meltdown 两个漏洞的根源。理解它们，要从推测执行留下的痕迹说起。

推测执行本身并不直接泄露数据。猜错的指令结果会被丢弃，寄存器的值也会恢复，看起来一切如常。问题出在微架构状态上：推测执行期间访问过的缓存行，会留在缓存里；分支预测器的训练结果，也会保留下来。这些状态是架构层面看不见的，却可以通过计时测量出来。攻击者正是利用这一点，把本不该读到的数据，编码进缓存的“在与不在”之中，再用计时侧信道逐字节读出。

Meltdown 的原理相对直接。它利用的是乱序执行与权限检查之间的时序差：一条本应被权限检查拦下的访内核内存的指令，在检查结果出来之前，已经把数据取到了缓存里。权限检查最终会触发异常，指令结果也被丢弃，但缓存里的痕迹已经留下。攻击者随后通过探测哪些缓存行被加载，反推出内核内存的内容。Meltdown 的影响面集中在允许用户程序与内核共享地址空间映射的设计上。

Spectre 则更难根除。它不依赖权限检查的时序差，而是主动“训练”分支预测器：先让分支预测器习惯走某一条路径，再诱使受害代码在推测执行中访问越界数据。Spectre 有多个变种，有的针对条件分支，有的针对间接分支，有的针对返回地址预测。共同点是攻击者不需要违反任何架构规则，只需要让处理器“猜”向自己想要的方向。

缓解措施沿着三条线展开。第一是隔离：把内核页表从用户地址空间中分离，让 Meltdown 的推测访问无处下手，这是操作系统层面最彻底的一招，代价是每次系统调用都要切换页表，增加了开销。第二是阻断推测：在关键的分支点插入屏障指令，强制处理器停下来等结果，代价是局部性能下降。第三是更新硬件：新一代处理器在微架构层面限制推测执行可触及的数据范围，或者让分支预测器的状态在特权级切换时隔离。

这些缓解措施都不是免费的。页表隔离让频繁进出内核的应用付出可观的性能代价；屏障指令用在热路径上同样会拖慢执行。业界为此争论过很久：安全与性能之间，到底该由谁买单。现实的答案是分层：对外的、不可信的执行环境用最严的隔离，对内的、可控的场景可以适当放宽。

Spectre 与 Meltdown 真正的启示不在漏洞本身，而在设计哲学上。几十年里，处理器设计默认微架构状态是不可见的、因而是安全的；这两个漏洞证明，只要状态能被计时测量，它就是可见的。此后每一代新处理器的安全评审里，“推测执行会留下什么痕迹”都成了一个必答题。速度与安全的天平，从此多了一枚实实在在的砝码。