处理器安全：侧信道攻击
2018年1月3日，Google Project Zero公开了两个将永久改变处理器设计的漏洞：Spectre和Meltdown。这些攻击的核心洞察令人不寒而栗——处理器为了性能而引入的投机执行机制，可以被攻击者利用来读取任意内存内容，包括其他进程和内核的敏感数据。投机执行的结果虽然在架构层面被丢弃了，但它在微架构层面留下了可观测的痕迹——Cache状态的变化。这些痕迹就是侧信道。这是处理器设计史上第一次，正确的硬件行为本身成为了安全漏洞的来源。
从本书的统一视角看——处理器设计的本质是在有限的晶体管预算和功耗约束下，通过投机和并行的层层叠加来逼近指令吞吐率的理论上限——Spectre/Meltdown揭示了"投机"的阴暗面。投机执行改变了微架构状态（Cache、TLB、BTB），这些状态变化不会被恢复机制（第 39.0 章）回滚——因为恢复机制的设计目标是恢复架构状态（寄存器、内存），而不是微架构状态。攻击者正是利用了这个架构/微架构的语义鸿沟：通过分支预测器（第 13.0 章–第 17.0 章的攻击面）诱导处理器投机地访问秘密数据，然后通过Cache（第 5.0 章的观测通道）读取投机留下的微架构痕迹。处理器设计中性能和安全的根本矛盾由此浮出水面：每一种投机优化都可能创造新的侧信道，而每一种安全防御都会削弱投机的性能收益。
2018年1月，Spectre和Meltdown漏洞的公开披露震动了整个计算机行业。这两个漏洞揭示了一个令人不安的事实：现代高性能处理器在追求极致性能的过程中所采用的核心微架构技术——推测执行（speculative execution）、乱序执行（out-of-order execution）、Cache层次结构、分支预测器——在安全性方面存在根本性的缺陷。攻击者可以利用这些微架构组件的行为差异，通过精心构造的程序来推断本不应被访问的秘密数据。这类攻击被统称为微架构侧信道攻击（microarchitectural side-channel attack）。
侧信道攻击并非全新的概念。早在1996年，Paul Kocher就展示了通过测量RSA解密操作的时间来恢复私钥的时间攻击（timing attack）。2005年，Daniel Bernstein演示了通过Cache时间差异攻击AES加密。然而，Spectre/Meltdown之所以影响深远，是因为它们将侧信道攻击的威胁从密码学实现（在特定代码路径中泄露密钥）扩展到了任意数据的读取——攻击者可以读取同一进程、其他进程甚至操作系统内核中的任意内存数据，而这一切都不需要任何软件漏洞，仅仅依赖于处理器硬件的正常行为。
本章将从微架构侧信道的基本概念出发，系统地分析主要的攻击技术和防御手段。我们首先区分侧信道与隐蔽信道的概念，建立时间侧信道的分析框架；然后深入讨论各类Cache侧信道攻击的原理和实现细节；接着重点分析以Spectre和Meltdown为代表的瞬态执行攻击，包括近年出现的Retbleed和Inception等新变种；最后讨论TLB侧信道、执行端口侧信道和电源侧信道等其他攻击面。对于每一类攻击，我们不仅解释其原理，还将深入分析处理器设计中的具体硬件防御措施及其性能代价，帮助处理器设计师在安全与性能之间做出合理权衡。
微架构侧信道概述
侧信道与隐蔽信道
在讨论微架构安全之前，有必要精确定义两个经常混淆的概念：侧信道（side channel）和隐蔽信道（covert channel）。
侧信道是指攻击者通过观察系统的非功能性行为（如执行时间、功耗、电磁辐射、Cache状态等）来推断系统处理的秘密信息。在侧信道攻击中，信息泄露是非预期的——系统的设计者并不打算通过这些物理或微架构可观测量来传递信息，但这些可观测量不可避免地与被处理的数据产生了关联。侧信道攻击的典型场景是：攻击者（观察者）与受害者（处理秘密数据的实体）之间没有合谋，攻击者单方面利用系统泄露的信息来推断秘密。
隐蔽信道则是指两个合谋的实体利用系统中本不用于通信的共享资源来进行秘密通信。在隐蔽信道中，发送方（sender）有意地调制某种共享状态（如Cache占用模式），接收方（receiver）通过检测该状态变化来读取信息。隐蔽信道的关键特征是双方合作——发送方故意编码信息，接收方知道编码方式并主动解码。
两者的核心区别可以用以下类比理解：侧信道相当于窃听者通过墙壁的振动来推断隔壁房间的谈话内容——谈话者并不知道（也不希望）墙壁会泄露信息；隐蔽信道则相当于两个囚犯通过敲击墙壁的节奏来传递消息——双方事先约定了编码方式。
| 属性 | 侧信道 | 隐蔽信道 |
|---|---|---|
| 参与方关系 | 攻击者单方面观察 | 发送方与接收方合谋 |
| 信息流方向 | 非预期泄露 | 有意通信 |
| 发送方行为 | 正常执行，无感知 | 主动调制共享状态 |
| 接收方行为 | 测量并推断 | 检测并解码 |
| 威胁模型 | 跨安全域信息泄露 | 绕过信息流控制策略 |
| 典型带宽 | 位/秒至千位/秒 | 千位/秒至兆位/秒 |
侧信道与隐蔽信道的对比
在处理器安全的语境中，侧信道和隐蔽信道往往使用相同的微架构机制（如Cache、TLB、分支预测器），区别仅在于攻击模型中参与方的角色。例如，Cache的Flush+Reload技术既可以用作侧信道攻击（攻击者监控受害者对共享库的访问模式），也可以用作隐蔽信道（两个合谋进程通过Cache状态传递信息）。在实际的安全分析中，隐蔽信道的带宽是衡量微架构资源隔离效果的重要指标——如果两个安全域之间通过某种微架构状态建立的隐蔽信道带宽很高（例如超过1 Mbps），则说明该资源的隔离措施不够充分。
**微架构侧信道的分类。**根据利用的物理/微架构可观测量，侧信道可以分为以下几类：
时间侧信道（Timing Side Channel）：通过测量操作的执行时间推断秘密信息。这是最常见的微架构侧信道类型，后续各节将重点讨论。
功耗侧信道（Power Side Channel）：通过测量处理器的瞬时功耗推断正在处理的数据。传统上需要物理探测，但RAPL等软件接口使其可远程利用。
电磁侧信道（Electromagnetic Side Channel）：通过测量处理器产生的电磁辐射推断内部操作。与功耗侧信道密切相关，但可以在更远的距离上进行。
故障注入侧信道（Fault Injection Side Channel）：通过对处理器注入故障（如电压毛刺、时钟毛刺、激光照射）并观察错误输出来推断内部状态。严格来说这属于主动攻击而非被动观测。
微架构状态侧信道（Microarchitectural State Side Channel）：通过探测微架构组件（Cache、TLB、分支预测器等）的状态变化推断信息。这是本章的重点内容。
设计提示
从处理器设计的角度看，微架构侧信道的根本原因在于资源共享（resource sharing）和状态依赖（state dependence）。现代处理器为了提高资源利用率和降低成本，在不同安全域（如不同进程、用户态与内核态、不同虚拟机）之间共享大量微架构资源：Cache、TLB、分支预测器、执行端口、填充缓冲区等。这些共享资源的状态会因为一个安全域的操作而改变，而另一个安全域可以通过观察自己的操作性能来检测这种变化。要彻底消除侧信道，就需要完全隔离这些共享资源——但这会带来不可接受的性能和面积代价。因此，处理器安全设计的核心挑战是在共享效率与隔离安全性之间找到合适的平衡点。
时间侧信道的基本原理
在所有微架构侧信道中，时间侧信道（timing side channel）是最常被利用的一类。其基本原理是：处理器执行某个操作所需的时间取决于该操作涉及的数据或状态，攻击者通过精确测量执行时间来推断这些数据或状态。
时间侧信道的信息泄露可以用互信息（mutual information）来形式化。设秘密数据为随机变量，攻击者观测到的执行时间为随机变量，则泄露的信息量为： $$\label{eq:ch50-mutual-info} I(S; T) = H(S) - H(S|T)$$ 其中是的熵（攻击前攻击者对的不确定性），是给定观测时间后的条件熵（攻击后的不确定性）。如果，则存在时间侧信道泄露。
在处理器微架构中，导致操作时间与数据相关的主要机制包括以下几类。
**（1）Cache命中与缺失。**这是最经典的时间侧信道来源。当处理器执行一条load指令时，如果目标数据在L1 Cache中命中，延迟仅为3–5个周期；如果在L2 Cache中命中，延迟为10–15个周期；如果在L3 Cache中命中，延迟为30–50个周期；如果需要访问主存，延迟则高达200–400个周期。这种巨大的时间差异（100倍以上）使得攻击者可以通过测量内存访问时间来判断某个地址是否在Cache中，进而推断受害者的访问模式。
**（2）分支预测命中与缺失。**分支指令的执行时间取决于分支预测器的状态。如果预测正确，处理器不需要冲刷流水线，分支的有效延迟几乎为零（被流水线隐藏）；如果预测错误，则需要冲刷已推测执行的指令并重新取指，惩罚为15–25个周期。攻击者可以通过训练（或观察）分支预测器的状态来推断受害者代码的控制流。
**（3）TLB命中与缺失。**TLB命中时地址翻译仅需1–2个周期（通过流水线隐藏），但TLB缺失需要进行页表遍历（page table walk），延迟为10–100个周期。攻击者可以通过TLB时间差异推断受害者的内存访问页面。
（4）功能单元竞争。在超标量处理器中，多条指令共享有限的功能单元（ALU、浮点单元、向量单元等）。如果受害者的指令占用了某个功能单元，攻击者的指令需要等待该功能单元释放，导致执行时间增加。这种端口竞争（port contention）可以泄露受害者正在执行的指令类型。
要利用时间侧信道，攻击者需要一个高精度的计时器（timer）。在x86处理器上，RDTSC（Read Time-Stamp Counter）指令可以读取处理器的时间戳计数器，提供亚纳秒级的时间分辨率。在ARM处理器上，类似的功能由PMCCNTR（Performance Monitor Cycle Counter）性能计数器提供。即使操作系统限制了对这些硬件计时器的直接访问，攻击者仍可以通过计数线程（counting thread）来构造高精度计时器：在一个独立的线程中持续递增一个共享变量，另一个线程在操作前后读取该变量的值来估算时间差。
计时器的精度与攻击的可行性。计时器的精度直接决定了攻击者能否可靠地区分不同的微架构事件。RDTSC提供的周期级精度（在3 GHz处理器上约0.33 ns）对于区分Cache命中（4周期）和缺失（200周期）绰绰有余。然而，操作系统和浏览器为了对抗侧信道攻击，可能会有意降低可用计时器的精度。例如，Web浏览器将JavaScript的performance.now()精度从5微秒降至100微秒甚至1毫秒。在这种低精度计时器下，攻击者仍然可以通过统计放大（statistical amplification）技术来恢复足够的时间信息：重复执行同一操作数百次并累计总时间，利用大数定律将平均值的测量精度提高到（为重复次数）。
高精度计时器的构造与对抗
除了硬件提供的计时器（如**RDTSC**、PMCCNTR），攻击者还可以使用多种软件方法构造高精度计时器：
**（1）计数线程。攻击者在一个独立的线程（或Web Worker中）中运行一个紧密循环，持续递增一个共享内存中的计数器变量。另一个线程在目标操作前后读取该计数器的值来估算时间差。计数线程的精度取决于递增操作的频率——在3 GHz的处理器上，单条递增指令约需1个周期，因此计数线程的精度约为0.33 ns，与RDTSC**相当。
**（2）SharedArrayBuffer时钟。**在Web浏览器中，SharedArrayBuffer允许多个Web Worker之间共享内存。一个Worker充当"计时器线程"（持续递增共享变量），另一个Worker在攻击操作前后读取共享变量。这种方法在2018年的Spectre浏览器攻击中被广泛使用，随后浏览器厂商通过默认禁用SharedArrayBuffer来阻断此路径。
（3）基于性能退化的时钟。即使所有高精度计时器都被禁用，攻击者仍然可以利用处理器的性能退化效应来间接测量时间。例如，通过测量一段固定计算量代码（如1000次循环迭代）在目标操作后的执行时间变化，来推断目标操作是否改变了Cache状态。这种方法的精度较低（约微秒级），但通过统计放大仍然可以区分Cache命中和缺失。
**（4）基于浏览器API的时钟。**即使performance.now()被降精度，某些浏览器API（如requestAnimationFrame的回调时间戳、CSS动画事件的时间戳、AudioContext的处理时间）仍然可能提供足够精度的时间信息。浏览器厂商需要持续审计和限制所有可能的时间信息泄露源。
硬件描述 1 — 处理器中的计时器安全设计
从处理器设计的角度，计时器的安全性是一个需要平衡的问题。高精度计时器（如**RDTSC**）对于性能分析和调试非常有价值，但也是侧信道攻击的关键使能器。
现代处理器提供了以下控制手段：
RDTSC禁用位：操作系统可以通过设置CR4.TSD（Time Stamp Disable）位来限制用户态对RDTSC的访问。当TSD=1时，用户态执行RDTSC会触发#GP异常。
RDTSC虚拟化：在VMX（虚拟机扩展）模式下，hypervisor可以通过VMCS的TSC-offset字段为每个VM提供偏移的时间戳，或者通过TSC-exit位拦截VM的RDTSC访问。
计时精度限制：ARM处理器的EL0（用户态）对PMU（性能监控单元）的访问可以通过PMUSERENR寄存器控制。在安全环境中，操作系统可以禁止用户态访问周期计数器。
噪声注入：学术界提出了在硬件计时器读数中注入随机噪声的方案，以降低侧信道攻击的信噪比。但这也会影响合法的性能分析应用。
然而，完全消除高精度计时的可能性几乎不可能——正如前文所述，攻击者可以通过计数线程等纯软件方法构造计时器。因此，计时器限制只能作为纵深防御中的一层，不能单独依赖。
信号放大与统计方法
当直接的时间测量精度不足以区分单次Cache命中和缺失时，攻击者可以使用统计放大技术来恢复信号：
**多次采样平均。**攻击者重复执行同一攻击操作次，累计总时间，然后计算平均值。根据大数定律，平均值的标准误差为，其中是单次测量的标准差。例如，如果单次测量的SNR为0.5（L2 vs L1的差异仅8个周期，噪声标准差约16个周期），则次测量后的平均值SNR提升到，足以可靠区分。
**概率密度估计。**更精细的分析方法是对多次测量的时间分布进行拟合。Cache命中和缺失的访问时间分别服从不同的分布（通常是偏态分布），通过混合高斯模型或核密度估计，可以将两种分布分离，即使它们的均值差异较小。
**互信息估计。**通过估计秘密数据与观测时间之间的互信息，可以量化侧信道泄露的信息量。如果（即使很小），理论上攻击者通过足够多的观测总能恢复全部秘密。互信息估计可以帮助处理器设计者评估特定微架构特征的信息泄露风险。
性能分析 1 — 侧信道攻击的理论信息上界
根据信息论，一个侧信道每次观测可以泄露的最大信息量为： $$ 其中是秘密数据的熵（对于位密钥，位），是在观测时间后的条件熵。
对于一个典型的Cache侧信道（区分L1命中vs L3命中，SNR10）：
每次Flush+Reload观测泄露约0.80.95位信息（接近1位，因为SNR很高）。
每次Prime+Probe观测泄露约0.30.6位信息（因为set级别的粒度和更高的噪声）。
每次Evict+Time观测泄露约0.050.2位信息（因为总执行时间的分辨率较低）。
恢复一个128位AES密钥理论上至少需要128 / 0.9 143次Flush+Reload观测（实际由于噪声和非理想信道需要更多次）。这与实验结果（200500次观测）一致。
恒定时间编程。从软件层面防御时间侧信道的核心方法是恒定时间编程（constant-time programming）：确保程序的执行时间和微架构行为不依赖于秘密数据。这要求：（1）不使用秘密数据作为分支条件；（2）不使用秘密数据作为内存访问的地址（避免秘密依赖的Cache行为）；（3）不使用秘密数据来选择不同的指令序列。恒定时间编程在密码学库中已经成为标准实践，如OpenSSL、libsodium等库都对关键的加密操作进行了恒定时间实现。然而，恒定时间编程对程序员要求极高，而且编译器的优化可能会无意中破坏恒定时间属性（例如将条件赋值优化为分支），因此需要专门的验证工具来确保恒定时间属性在编译后仍然保持。
性能分析 2 — Cache时间差异作为侧信道的信号强度
Cache命中与缺失的时间差异决定了侧信道的信噪比（signal-to-noise ratio, SNR）。以一个典型的现代处理器为例，L1 Cache命中延迟约为4个周期，主存访问延迟约为200个周期，差值为196个周期。假设测量噪声（由中断、调度抖动等引起）的标准差为个周期，则信噪比约为： $$
| Cache层级 | 命中延迟（周期） | 与L1差值 | 典型SNR |
|---|---|---|---|
| L1 Cache | 4 | – | – |
| L2 Cache | 12 | 8 | 0.4 |
| L3 Cache | 40 | 36 | 1.8 |
| 主存 | 200 | 196 | 9.8 |
从表中可以看出，L1与L2之间的时间差异仅8个周期，SNR不足1，很难可靠区分；而L1与主存之间的差异高达196个周期，SNR接近10，可以非常可靠地区分。这就是为什么大多数Cache侧信道攻击选择在L1（或L2）与LLC（或主存）之间进行区分，而不是在相邻的Cache层级之间。
Cache侧信道攻击
回顾第 5.0 章中讨论的Cache层次结构：L1命中4周期、L2命中12周期、L3命中40周期、DRAM200周期。这种100倍量级的时间差异正是Cache侧信道的物理基础——攻击者通过测量访问时间就能判断某个地址是否在Cache中。同时，第 13.0 章–第 17.0 章中讨论的分支预测器是Spectre攻击的核心攻击面：攻击者通过训练分支预测器的历史表，诱导受害者代码在投机路径上访问秘密数据。这些为性能而设计的微架构组件，在安全视角下都成为了信息泄露的通道。
Cache层次结构是现代处理器中被利用最广泛的侧信道攻击面。由于Cache的存在是为了弥补处理器速度与内存速度之间的巨大差距，其"命中快、缺失慢"的特性本身就构成了一个天然的时间侧信道。根据攻击者如何操纵和探测Cache状态，Cache侧信道攻击可以分为几种主要技术。
Flush+Reload
Flush+Reload是2014年由Yarom和Falkner提出的一种高分辨率Cache侧信道攻击技术。它是目前已知精度最高的Cache侧信道攻击，可以达到单个Cache行的监控粒度。
前提条件。Flush+Reload攻击要求攻击者和受害者之间存在共享内存（shared memory），通常通过以下机制实现：（1）操作系统的写时复制（Copy-on-Write, CoW）机制——fork之后父子进程共享物理页面直到写操作发生；（2）共享库（shared library）——多个进程使用同一个动态链接库时，操作系统将库的代码段映射到相同的物理页面；（3）页面去重（page deduplication）——虚拟机管理器（如KSM）检测内容相同的页面并合并。
**攻击步骤。**Flush+Reload攻击分为三个阶段：
（1）Flush阶段。攻击者使用CLFLUSH（x86）或**DC CIVAC（ARM）指令，将目标Cache行从整个Cache层次结构**（包括L1、L2、L3）中驱逐。由于共享内存的存在，攻击者和受害者使用的是同一个物理地址，因此攻击者的flush操作会影响受害者后续的访问延迟。
（2）**等待阶段。**攻击者等待一段时间（通常为几百到几千个周期），让受害者执行可能访问目标Cache行的操作。
（3）**Reload阶段。**攻击者重新访问目标地址，并测量访问时间。如果受害者在等待期间访问了该Cache行，则该行已被重新加载到Cache中，reload的时间将很短（Cache命中，约4个周期）；如果受害者没有访问，则该行仍然不在Cache中，reload的时间将很长（主存访问，约200个周期）。
Flush+Reload的攻击粒度为单个Cache行（通常64字节），这意味着攻击者可以监控受害者对共享库中具体函数甚至具体代码分支的访问情况。例如，在T-table实现的AES加密中，不同的密钥字节会导致访问不同的查找表条目（位于不同的Cache行中），攻击者可以通过Flush+Reload监控所有查找表的Cache行，从而恢复AES密钥。
Flush+Reload的完整攻击实现
为了更深入地理解Flush+Reload攻击，下面给出一个完整的攻击实现流程，以攻击AES T-table查找为例。
**步骤1：识别共享库和目标函数。**攻击者首先确定受害者使用的密码学库（如OpenSSL的libcrypto.so）中AES T-table的内存位置。AES的T-table实现使用4个查找表（Te0–Te3），每个表包含256个4字节条目，占据字节 = 16个Cache行。
**步骤2：建立共享内存映射。**由于共享库的代码段和只读数据段在多个进程间共享物理页面，攻击者可以通过简单地链接同一版本的OpenSSL库来获得对T-table物理页面的共享访问。操作系统自动将攻击者和受害者的虚拟地址映射到相同的物理页面。
**步骤3：Flush阶段——清除目标Cache行。攻击者对所有16个T-table Cache行执行CLFLUSH**指令：
// 刷新Te0表的所有16个Cache行
for (int i = 0; i < 16; i++) {
_mm_clflush((void*)(te0_addr + i * 64));
}
// 插入内存屏障确保flush完成
_mm_mfence();**步骤4：等待受害者执行。**攻击者等待受害者执行一轮AES加密。等待时间需要仔细调节——太短则受害者可能尚未开始加密，太长则受害者可能已经执行了多轮加密，Cache中的T-table条目反映的是最后一轮加密的访问模式而非第一轮。典型的等待时间为5002000个时钟周期。
**步骤5：Reload阶段——测量每个Cache行的访问时间。**攻击者对每个T-table Cache行执行一次load并精确测量访问时间：
uint64_t t1, t2;
int cache_hit[16];
for (int i = 0; i < 16; i++) {
t1 = __rdtsc(); // 读取时间戳计数器
volatile uint8_t val = *(uint8_t*)(te0_addr + i * 64);
t2 = __rdtsc();
cache_hit[i] = (t2 - t1) < THRESHOLD; // 阈值约100周期
}如果cache_hit[i]为1，说明受害者在加密过程中访问了Te0表的第个Cache行（即查找了索引在范围内的T-table条目）。
**步骤6：密钥字节恢复。**AES的第一轮查找表访问使用的索引为。如果攻击者知道明文字节，并且通过Flush+Reload确定了访问了哪个Cache行（即的值），则密钥字节的可能值被缩小到4个。通过多轮加密的观测（使用不同的明文），可以唯一确定密钥字节的值。
**步骤7：重复收集。**攻击者重复步骤3–6数百到数千次，使用统计分析（如频率分析或互信息计算）来提高密钥恢复的可靠性。在典型实验中，约需200500轮加密观测即可可靠恢复完整的128位AES密钥。
性能分析 3 — Flush+Reload攻击的性能指标
以攻击AES-128 T-table实现为例：
每轮攻击时间：约s（@3 GHz）
所需加密观测次数：200500次
总攻击时间：约s = 2.5 ms
密钥恢复成功率：99%（在200次观测后）
信息泄露带宽：约16字节密钥 / 2.5 ms = 6.4 KB/s
这些数字表明，在受害者持续进行AES加密操作的场景下，Flush+Reload可以在毫秒级时间内完整恢复AES密钥。这个速度远快于暴力搜索种可能的密钥——侧信道攻击将密码学问题从计算问题转化为物理测量问题。
Flush+Reload的优势与局限。与其他Cache侧信道技术相比，Flush+Reload具有以下优势：（1）高精度——单Cache行粒度，几乎没有误报；（2）低噪声——直接测量目标地址的访问时间，不受其他Cache活动影响；（3）跨核攻击——由于flush操作影响整个Cache层次结构（包括共享的LLC），攻击者和受害者可以运行在不同的处理器核心上。其主要局限是需要共享内存——如果操作系统禁用了页面共享或去重功能，Flush+Reload就无法使用。
Flush+Reload的防御措施
针对Flush+Reload的防御可以从多个层面入手：
**（1）禁用共享页面。**操作系统可以禁用写时复制页面的物理共享（每个进程使用独立的物理页面拷贝），或者禁用KSM（Kernel Same-page Merging）页面去重功能。这消除了Flush+Reload的前提条件——攻击者和受害者不再共享物理页面。代价是内存占用增加（共享库的代码段不再共享），但对于安全敏感的环境这是可接受的。
（2）限制CLFLUSH指令。操作系统可以通过设置CR0.CD（Cache Disable）或通过虚拟化拦截CLFLUSH指令。但这会影响所有合法的Cache管理操作，代价过大。一种更精细的方案是速率限制CLFLUSH——限制单位时间内CLFLUSH指令的执行次数，使Flush+Reload攻击的采样率降低到无法有效攻击的水平。
（3）Cache分区。为不同的安全域分配独立的Cache way或Cache set，使得一个安全域的Cache操作（包括flush）不会影响另一个安全域的Cache内容。Intel的CAT（Cache Allocation Technology）和CDP（Code/Data Prioritization）提供了LLC way级别的分区能力。ARM的MPAM（Memory Partitioning and Monitoring）提供了更灵活的Cache分区机制。
**（4）加密的Cache索引。**如前文Cache随机化一节所述，使用密钥相关的映射函数来随机化地址到Cache set的映射，使攻击者无法预测共享地址在Cache中的位置。
设计权衡 1 — Flush+Reload防御的安全性-性能-兼容性权衡
各种Flush+Reload防御措施在三个维度上存在权衡：
禁用共享页面：安全性高（彻底消除攻击前提），性能影响低中（内存占用增加约515%），兼容性好（不影响应用行为）。
限制CLFLUSH：安全性中（只降低攻击速度，不能完全阻止），性能影响低（很少有合法应用频繁使用CLFLUSH），兼容性好。
Cache分区：安全性高（物理隔离），性能影响中高（有效Cache容量减少），兼容性好。
Cache随机化：安全性中高（增加攻击复杂度但不保证完全安全），性能影响低（2%），兼容性好。
在实际部署中，通常需要组合多种防御措施以获得足够的安全保证。例如，云服务提供商可能同时启用"禁用KSM"（防Flush+Reload）+"Cache分区"（防Prime+Probe）+"eIBRS"（防Spectre v2）来保护多租户环境中的虚拟机隔离。
Flush+Reload的跨虚拟机攻击
在虚拟化环境中，Flush+Reload的跨VM攻击依赖于内存去重（memory deduplication）机制。虚拟机管理器（如KVM+KSM）会扫描不同VM的内存页面，将内容相同的页面合并为一个物理页面（写时复制）。如果攻击者VM和受害者VM运行相同版本的操作系统或应用程序，它们的代码段和只读数据段很可能被合并。
攻击者可以通过以下方式检测页面是否被合并：分配一个页面，写入与受害者可能使用的共享库代码段相同的内容，等待KSM扫描周期（通常几十秒到几分钟）完成合并。然后使用Flush+Reload测试该页面的某个Cache行——如果受害者正在执行对应的代码，攻击者的reload会观测到Cache命中。
防御。最直接的防御是在安全敏感的虚拟化环境中禁用KSM（或类似的页面去重功能）。Linux内核提供了/sys/kernel/mm/ksm/run接口来动态启用或禁用KSM。主要的云服务提供商（AWS、Azure、GCP）已经在其生产环境中默认禁用了跨VM的页面去重。
硬件描述 2 — CLFLUSH指令的微架构行为
x86的**CLFLUSH指令将包含指定地址的Cache行从所有Cache层级**中无效化（invalidate）。在多核系统中，如果目标Cache行在其他核心的私有Cache中也有副本（处于Shared或Exclusive状态），CLFLUSH还会触发一致性协议将这些副本也无效化。这个行为对Flush+Reload攻击至关重要——它确保了flush操作不仅清除本核心的Cache，还清除了受害者核心的Cache，使得受害者的下次访问必然产生Cache缺失并重新加载。
Intel在Skylake及之后的处理器中引入了**CLFLUSHOPT**（优化的Cache行刷新），它与CLFLUSH的语义相同，但具有更弱的排序约束——CLFLUSHOPT相对于其他CLFLUSHOPT和stores是弱序的（只有SFENCE才能保证其与后续写操作的顺序），因此可以并行执行多个flush操作，提高吞吐量。从安全角度看，CLFLUSHOPT同样可以被Flush+Reload攻击利用。
值得注意的是，CLFLUSH/CLFLUSHOPT是非特权指令——任何用户态程序都可以执行它们，这是Flush+Reload攻击在x86平台上特别有效的重要原因。在ARM平台上，等效的**DC CIVAC**指令在EL0（用户态）的可用性取决于SCTLR_EL1.UCI位的设置。
Prime+Probe
Prime+Probe是一种不需要共享内存的Cache侧信道攻击技术，最早由Osvik、Shamir和Tromer在2006年提出。它通过操纵Cache set的替换行为来探测受害者的内存访问模式。
攻击原理。Prime+Probe利用了Cache的组相联（set-associative）结构。在一个路组相联的Cache中，每个Cache set有个Cache行。当一个Cache set中的个行都已被占用时，新的Cache行的加载必须驱逐（evict）该set中已有的一行。Prime+Probe攻击分为两个阶段：
（1）Prime阶段。攻击者分配一组精心选择的内存地址（称为eviction set），这些地址恰好映射到目标Cache set中。攻击者访问这些地址，将目标Cache set的所有路都填充为自己的数据。在Prime完成后，目标Cache set中完全是攻击者的数据。
（2）**Probe阶段。**等待受害者执行一段时间后，攻击者重新访问eviction set中的所有地址，并测量每次访问的时间。如果受害者在等待期间访问了映射到同一Cache set的地址，受害者的数据会驱逐攻击者的某些Cache行，导致攻击者在probe阶段的某些访问变为Cache缺失（时间较长）。通过检测哪些Cache set中发生了驱逐，攻击者可以推断受害者访问了哪些Cache set。
Eviction Set的构造。Prime+Probe的关键技术难点在于构造eviction set——找到一组恰好映射到同一Cache set的地址。在使用物理地址索引的Cache（大多数L2和L3 Cache）中，攻击者需要知道虚拟地址到物理地址的映射关系才能精确构造eviction set。然而，在现代操作系统中，攻击者通常无法直接获取物理地址。
为解决这个问题，研究者提出了基于冲突测试的eviction set构造算法：攻击者分配一大块内存，然后通过反复的访问-驱逐测试来识别哪些地址映射到同一Cache set。具体来说，对于一个路组相联的LLC，攻击者首先选择一组候选地址（远多于个），然后逐个移除候选地址并测试剩余地址是否仍能驱逐目标行。如果移除某个地址后仍然可以驱逐，说明该地址与目标行不在同一set中，可以安全移除；如果移除后无法驱逐，说明该地址与目标行在同一set中，必须保留。通过这种方式，攻击者可以将候选集缩减到恰好个地址，形成一个精确的eviction set。
Prime+Probe的攻击粒度与精度。Prime+Probe的监控粒度为Cache set级别，而不是Flush+Reload的Cache行级别。在一个4096-set的L1 Cache中，每个set覆盖的地址范围为（对于4 KB页面，同一set包含个页面中的对应行），因此Prime+Probe无法精确区分同一set中来自不同页面的访问。尽管如此，对于许多攻击场景（如AES密钥恢复），set级别的粒度已经足够。
Prime+Probe的优势。与Flush+Reload相比，Prime+Probe最大的优势是不需要共享内存。攻击者只需要能够分配足够多的内存来构造eviction set，不需要与受害者共享任何物理页面。这使得Prime+Probe可以在云环境中跨虚拟机使用（攻击者VM和受害者VM共享同一个物理处理器的LLC），也可以在浏览器环境中通过JavaScript实现（利用SharedArrayBuffer或其他内存分配机制）。
案例研究 1 — 利用Prime+Probe攻击Last-Level Cache的跨核攻击
2015年，Liu等人展示了针对Intel处理器Last-Level Cache（LLC）的Prime+Probe攻击。由于LLC在同一物理封装内的所有核心之间共享，这种攻击可以跨核心实施，大大扩展了攻击面。
攻击面临的主要挑战是LLC的slice结构。Intel处理器将LLC分为多个slice，每个slice与一个核心关联。地址到slice的映射使用一个未公开的哈希函数（基于物理地址的多个位进行XOR运算）。研究者通过逆向工程恢复了这个哈希函数，从而能够精确地构造映射到特定LLC slice和set的eviction set。
在实验中，攻击者和受害者运行在不同的处理器核心上（甚至可以运行在不同的虚拟机中）。攻击者能够以约每5微秒一次的采样率监控受害者的LLC访问模式，并成功从GnuPG的ElGamal解密过程中恢复了96%以上的密钥位。整个攻击过程中，攻击者与受害者之间没有任何共享内存，完全通过LLC的竞争行为实现信息泄露。
Evict+Time
Evict+Time是一种较早的Cache侧信道技术，由Osvik等人在2006年与Prime+Probe一同提出。与Prime+Probe相比，Evict+Time的监控粒度较粗，但实现更加简单。
攻击步骤。Evict+Time的基本思路是测量受害者操作的总执行时间是否因为Cache状态的变化而发生变化：
（1）**基准测量。**在Cache处于"温暖"（warm）状态时调用受害者的操作（如一次加密调用），记录执行时间。此时受害者需要的大部分数据和代码都在Cache中。
（2）**驱逐阶段。**攻击者有选择地驱逐Cache中特定set的内容。驱逐可以通过访问大量映射到目标set的地址来实现（类似Prime+Probe的Prime阶段），也可以通过CLFLUSH指令实现。
（3）**重新测量。**再次调用受害者的同一操作，记录执行时间。如果驱逐的set包含受害者操作需要的数据或代码，则；否则。
通过系统地驱逐不同的Cache set并观察对受害者执行时间的影响，攻击者可以推断受害者在执行过程中访问了哪些Cache set。结合对受害者代码和数据布局的了解（例如AES查找表在内存中的位置），攻击者可以将Cache set的访问模式与秘密数据关联起来。
**Evict+Time的局限性。**与Flush+Reload和Prime+Probe相比，Evict+Time的主要劣势在于：（1）需要多次调用受害者操作——每次驱逐只能测试一个或几个Cache set，完整攻击需要重复调用受害者操作多次（与Cache set数量成正比），这在某些场景下不切实际；（2）精度较低——测量的是总执行时间的变化，容易受到其他因素（如中断、调度）的干扰；（3）需要对受害者有触发能力——攻击者需要能够重复触发受害者的操作。
**三种Cache攻击技术的对比。**表表 50.3总结了Flush+Reload、Prime+Probe和Evict+Time三种主要Cache侧信道攻击技术的关键特征。
| 特征 | Flush+Reload | Prime+Probe | Evict+Time |
|---|---|---|---|
| 监控粒度 | Cache行（64B） | Cache set | Cache set |
| 需要共享内存 | 是 | 否 | 否 |
| 跨核攻击 | 是（通过LLC） | 是（通过LLC） | 受限 |
| 跨VM攻击 | 有限（需页面去重） | 是 | 受限 |
| 典型带宽 | 500 KB/s | 100 KB/s | 10 KB/s |
| 需要特殊指令 | 是（CLFLUSH） | 否 | 否 |
| 测量方式 | 单地址reload时间 | eviction set访问时间 | 受害者总执行时间 |
| 噪声抗性 | 高 | 中 | 低 |
三种主要Cache侧信道攻击技术的对比
从表中可以看出，Flush+Reload在精度和带宽上都优于其他两种技术，但它要求共享内存的前提条件限制了其适用场景。Prime+Probe不需要共享内存，因此在云环境和跨VM场景中最为实用。Evict+Time由于精度最低，在实际攻击中的使用较少，但其简单性使其成为侧信道研究的入门技术。
Cache随机化防御
针对Cache侧信道攻击，研究者和工业界提出了多种防御机制。其中，Cache随机化（Cache randomization）是一类特别有前景的硬件防御方案，它通过打乱地址到Cache set的映射关系来使得攻击者难以构造eviction set或预测受害者的Cache行为。
基本思路。传统Cache使用地址的固定位作为set索引（index），这使得攻击者可以预测任何已知地址映射到哪个Cache set。Cache随机化的核心思想是在地址与set索引之间引入一个密钥相关的映射函数： $$\label{eq:ch50-cache-random} \mathrm{set_index} = f(address, key)$$ 其中是一个对攻击者保密的随机密钥，是一个密码学或伪随机函数。不同的安全域（进程、虚拟机）使用不同的密钥，因此即使两个域访问同一物理地址，它们的数据也会被映射到不同的Cache set中，从而隔离了干扰。
**CEASER。**CEASER（2018年，Qureshi提出）是第一个实用的Cache随机化方案。它使用一个轻量级的加密函数（Low-Latency Block Cipher, LLBC）将物理地址加密后作为LLC的set索引。加密密钥定期更换（称为key remap），以应对攻击者可能通过长时间观察来逆向推断映射关系的情况。CEASER的硬件开销主要在于加密函数的延迟——LLBC的延迟约为1–2个周期，对于L1/L2这种延迟敏感的Cache来说偏高，但对于LLC（本身延迟就在30–50个周期）来说可以接受。
CEASER-S。CEASER-S（2019年）在CEASER的基础上引入了分区（skewing），将Cache的每一路使用不同的随机映射。这意味着即使攻击者能够找到与目标在某一路中映射到同一set的地址，这些地址在其他路中的映射位置是完全不同的。攻击者需要找到在所有路中都映射到同一set的地址集合，这在随机映射下的概率极低。
ScatterCache。ScatterCache（2019年，Werner等人提出）更进一步，对Cache的每一路使用独立的密钥和索引函数。在一个路的ScatterCache中，一个Cache行可以被放置在个不同set中的任意一个。这类似于一个极端的skewed Cache，使得构造eviction set在计算上变得不可行（需要找到在所有个随机映射中都冲突的地址集合）。
硬件描述 3 — Cache随机化的硬件实现代价
Cache随机化方案的硬件代价主要包括以下几个方面：
**（1）加密/映射函数的面积和延迟。**典型的LLBC（如PRINCE的简化版本）在5 nm工艺下的面积约为0.001 mm，延迟约为1–2个周期。对于ScatterCache，每一路需要一个独立的映射函数，路Cache需要个映射单元，总面积约为（16路时约0.016 mm）。
**（2）密钥存储。**每个安全域需要一个或多个密钥（ScatterCache中每路一个密钥）。密钥长度通常为64–128位，如果需要支持个并发安全域，密钥存储的总容量为位。对于个安全域和路，需要位 KB。
**（3）Key remap的性能代价。**当密钥更换时，所有使用旧密钥映射的Cache行都需要被重新映射到新的位置（或者简单地失效化），这会导致短暂的性能下降。CEASER的原始论文建议每100ms更换一次密钥，每次remap在后台渐进式地迁移Cache行，对性能的影响约为0.5%–1%。
**（4）对Cache查找延迟的影响。**在传统Cache中，地址的set索引位可以在地址翻译完成前就从虚拟地址中提取（VIPT Cache），实现与TLB查找并行的set索引。但在Cache随机化方案中，映射函数需要物理地址作为输入，因此set索引的计算必须等待TLB翻译完成后才能开始。这对L1 Cache的延迟影响较大（增加1–2个周期），但可以通过way-prediction或推测索引来缓解。
设计提示
Cache随机化是目前对抗Cache侧信道攻击最有前景的硬件防御手段之一，但它并非万能药。它主要防御的是基于eviction的攻击（如Prime+Probe），通过使攻击者难以构造eviction set来挫败攻击。然而，Flush+Reload攻击不依赖eviction set构造（它直接使用共享地址），因此Cache随机化对Flush+Reload的防御效果有限。要全面防御Cache侧信道，还需要结合其他措施：禁用共享内存（防Flush+Reload）、Cache分区（partition）提供强隔离、恒定时间编程（constant-time programming）消除秘密依赖的Cache访问模式等。
瞬态执行攻击
瞬态执行攻击（Transient Execution Attack）是2018年以来处理器安全领域最重要的发现。与传统的Cache侧信道攻击不同，瞬态执行攻击利用处理器的推测执行机制来执行本不应该执行的指令，并在推测执行被撤销之前通过侧信道将数据泄露到攻击者可观测的微架构状态中。
瞬态执行的概念。在现代乱序处理器中，当遇到分支指令或可能触发异常的指令时，处理器会推测性地继续执行后续指令，而不是等待分支结果确定或异常检查完成。如果推测正确，这些指令的结果被提交（commit），成为程序的正式执行结果；如果推测错误，这些指令被撤销（squash），其对架构状态（寄存器、内存）的影响被完全回退。然而——这是瞬态执行攻击的关键洞察——微架构状态的变化并不会被回退。推测执行的指令可能已经将数据加载到Cache中、改变了分支预测器的状态、占用了TLB条目，这些微架构副作用在推测执行被撤销后仍然保留。攻击者可以通过侧信道（通常是Cache侧信道）来观测这些微架构副作用，从而获取推测执行期间读取的数据。
我们将推测执行期间执行但最终被撤销的指令称为瞬态指令（transient instruction），它们的执行窗口称为瞬态执行窗口（transient execution window）。瞬态执行窗口的大小取决于推测执行被发现错误所需的时间：对于分支误预测，窗口大小约为15–25个周期（分支解析延迟）；对于需要TLB查找或页表遍历才能确定的异常，窗口可能更大。
Spectre v1（边界检查旁路）
Spectre v1（CVE-2017-5753），也称为边界检查旁路（Bounds Check Bypass），是最广为人知的瞬态执行攻击。它利用条件分支预测器的行为来使处理器推测性地绕过边界检查，从而读取越界的数据。
**攻击原理。**考虑以下在受害者进程中常见的代码模式：
if (x < array1_size) { // 边界检查
y = array2[array1[x] * 4096]; // 依赖于array1[x]的值
}正常情况下，if语句的边界检查确保了x不会超出array1的范围。然而，Spectre v1攻击通过以下步骤绕过这个检查：
（1）**训练分支预测器。**攻击者多次以合法的x值（）调用受害者代码，使条件分支预测器"学习"到该分支通常为"taken"（进入if分支体）。
（2）**驱逐边界值。**攻击者将array1_size从Cache中驱逐（例如使用CLFLUSH）。这样当处理器下次需要读取array1_size来评估分支条件时，将产生Cache缺失，需要较长时间才能获取该值。
（3）发起攻击。攻击者使用一个越界的x值调用受害者代码。由于array1_size不在Cache中，分支条件的评估需要等待数百个周期的内存访问。在此期间，分支预测器基于先前的训练预测该分支为"taken"，处理器推测性地进入if分支体。
（4）**推测执行越界访问。**在推测执行中，处理器执行array1[x]——由于x越界，这实际上读取了array1数组之外的内存，获取了一个秘密字节值。然后处理器计算array2[s * 4096]并将对应的Cache行加载到Cache中。
（5）**检测推测执行的副作用。**当array1_size最终从内存中加载完成后，处理器发现分支预测错误（），撤销推测执行的所有指令。然而，array2[s * 4096]对应的Cache行仍然留在Cache中。攻击者随后通过Flush+Reload（或Prime+Probe）扫描array2的所有256个可能的Cache行（对应），找到唯一一个命中Cache的行，其索引即为秘密字节的值。
Spectre v1 PoC代码的详细分析
下面给出一个更完整的Spectre v1概念验证（PoC）代码，并逐行分析其攻击机制：
#define ARRAY1_SIZE 16
uint8_t array1[ARRAY1_SIZE] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16};
uint8_t array2[256 * 4096]; // 探测数组，每个元素间隔4096字节
uint8_t temp = 0;
char *secret = "SECRET DATA HERE"; // 待泄露的秘密数据
void victim_function(size_t x) {
if (x < ARRAY1_SIZE) {
temp &= array2[array1[x] * 4096];
}
}
// 攻击主循环：逐字节读取秘密数据
void attack() {
int results[256] = {0};
size_t malicious_x = (size_t)(secret - (char*)array1); // 越界偏移
for (int tries = 0; tries < 1000; tries++) {
// 刷新array2的所有256个探测页面
for (int i = 0; i < 256; i++)
_mm_clflush(&array2[i * 4096]);
// 训练分支预测器：用合法值调用5次
for (int j = 0; j < 5; j++) {
_mm_clflush(&array1_size); // 确保边界值不在cache中
victim_function(j % ARRAY1_SIZE); // 合法调用
}
// 发起攻击：用越界值调用
_mm_clflush(&array1_size);
_mm_mfence();
victim_function(malicious_x); // 越界调用
// 探测array2，找到被推测加载的cache行
for (int i = 0; i < 256; i++) {
int idx = ((i * 167) + 13) & 255; // 随机化探测顺序
uint64_t t1 = __rdtsc();
temp &= array2[idx * 4096];
uint64_t dt = __rdtsc() - t1;
if (dt < 80) results[idx]++; // cache命中阈值
}
}
// results数组中计数最高的索引即为秘密字节的值
}这段代码的关键细节值得逐一分析：
**（1）探测数组的4096字节间距。**array2的每个元素间隔一个页面（4096字节），共占据MB。这样做有两个目的：(a) 确保256个探测点位于不同的Cache行中，避免混淆；(b) 确保它们位于不同的页面中，阻止硬件预取器跨页面预取干扰结果。
**（2）分支预测器训练。**攻击代码在越界调用之前用5次合法调用训练分支预测器。这建立了"该分支总是taken"的预测历史。同时，每次训练前都将array1_size从Cache中刷出——这确保在最后一次（越界）调用时，分支条件的计算需要等待Cache miss，给推测执行创造足够长的时间窗口。
**（3）探测顺序的随机化。**探测array2时使用了的公式来随机化探测顺序（而非按0, 1, 2, ...顺序）。这是为了避免处理器的硬件预取器检测到顺序访问模式并预取未被推测访问的Cache行，造成误报。
**（4）temp &= ...的作用。**使用&=操作确保编译器不会优化掉对array2的访问（因为temp被声明为全局变量且可能被外部使用），同时AND操作本身不会产生有意义的副作用。
（5）越界偏移的计算。malicious_x计算为，即secret字符串相对于array1的偏移量。当这个值被用于array1[x]时，实际读取的是secret字符串的内容。这种"相对寻址"技巧使得攻击者可以读取同一进程地址空间中的任意数据。
设计提示
Spectre v1 PoC代码展示了一个深刻的安全教训：即使程序逻辑是正确的（边界检查存在且有效），处理器的推测执行仍然可以绕过检查。这使得传统的软件安全审计方法（代码审查、静态分析）无法检测到Spectre类漏洞——因为漏洞不在代码的逻辑正确性中，而在代码的微架构执行行为中。这一发现推动了"安全感知编译器"（如LLVM的Speculative Load Hardening）和"微架构安全验证"工具的发展。
为什么乘以4096？在攻击代码中，array1[x]的值被乘以4096（即，一个页面的大小）后用于索引array2。这样做的目的是确保不同的秘密字节值映射到不同的Cache行和不同的页面，避免Cache预取器的干扰——现代处理器的硬件预取器通常不会跨页面预取，因此只有被推测执行直接访问的Cache行会被加载，而相邻的Cache行不会被预取器"误杀"。
Spectre v1的通用性。Spectre v1的危险在于它利用的是一种极其常见的编程模式——边界检查后的数组访问。几乎所有的数组访问都受到边界检查的保护，而所有处理器的分支预测器都可能在边界检查分支上预测错误。这意味着Spectre v1影响几乎所有现代处理器（Intel、AMD、ARM、RISC-V），而且受害者代码不需要包含任何bug——攻击利用的是正确代码在推测执行下的行为。
软件防御：推测执行屏障。针对Spectre v1，最直接的软件防御是在边界检查后插入推测执行屏障（speculation barrier），阻止处理器在分支结果确定前推测执行数据依赖的指令。在x86上，Intel推荐使用**LFENCE指令，它会阻止后续指令的推测执行直到LFENCE之前的所有指令完成。在ARM上，等效的指令是CSDB**（Conditional Speculation Dependency Barrier）。
if (x < array1_size) {
lfence(); // 阻止推测执行
y = array2[array1[x] * 4096];
}然而，LFENCE会完全阻止推测执行，严重影响处理器流水线的利用率。在分支密集的代码中，大量的LFENCE指令可能导致10%–30%的性能下降。因此，编译器需要智能地只在潜在危险的位置插入屏障（如Linux内核中的array_index_nospec()宏），而不是在每个分支后都插入。
硬件防御方向。更优雅的硬件防御是让处理器在推测执行期间阻止信息泄露，而不是阻止推测执行本身。例如：（1）推测加载限制——推测执行的load指令不允许将数据转发给后续的地址计算指令，从而阻止秘密数据被编码到Cache访问模式中（但会降低推测执行的有效性）；（2）推测性Cache分区——推测执行的指令使用一个隔离的Cache区域，在推测被确认正确后才将数据迁移到正式Cache中（类似于InvisiSpec方案）；（3）延迟Cache填充——推测执行的load在命中Cache时正常返回数据，但在缺失时不填充Cache，直到指令被提交后才进行Cache填充。
硬件描述 4 — InvisiSpec：推测不可见的内存访问
InvisiSpec（2018年，Yan等人提出）是学术界提出的一种针对瞬态执行攻击的硬件防御方案。其核心思想是让推测执行的load指令对Cache不可见——推测执行期间的内存访问不改变Cache的状态，从而消除通过Cache侧信道泄露推测执行结果的可能性。
InvisiSpec的工作机制如下：
（1）推测加载缓冲区（Speculative Buffer, SB）。处理器在L1 Cache旁边增加一个小型缓冲区。推测执行的load将数据加载到SB中而不是Cache中，后续推测指令从SB中读取数据。SB对Cache层次结构是不可见的——它不会引起Cache行的替换或移动。
（2）验证与暴露。当推测执行被确认正确（load到达ROB头部并准备提交）时，处理器执行一次验证加载（validation load），将数据从SB正式"暴露"到Cache中。如果推测错误，SB中的数据被丢弃，Cache状态保持不变。
（3）一致性协议集成。SB中的数据需要与多核的一致性协议正确集成，确保即使数据暂存在SB中，一致性语义仍然被满足。
InvisiSpec的性能代价约为5%–10%的IPC下降（由于验证加载增加了提交阶段的延迟）。其面积代价主要是SB的存储——对于一个支持64个in-flight load的处理器，SB需要约 KB的存储。尽管InvisiSpec尚未在商业处理器中实现，但它代表了一种重要的设计思路：通过在微架构中增加事务性状态管理来隔离推测执行的副作用。
案例研究 2 — Spectre v1在浏览器中的利用
Spectre v1的一个特别令人担忧的攻击面是Web浏览器。现代浏览器允许网页运行JavaScript代码，而JavaScript运行在与浏览器其他组件（如密码管理器、Cookie存储）相同的进程中。Google Project Zero在2018年演示了以下攻击：
攻击者构造一个恶意网页，其中的JavaScript代码：（1）使用SharedArrayBuffer和高精度定时器（performance.now()）来测量内存访问时间；（2）训练浏览器JIT编译器生成的机器码中的条件分支预测器；（3）利用Spectre v1的推测执行来读取浏览器进程中的任意内存，包括其他标签页的Cookie、密码等敏感数据。
这一发现导致所有主要浏览器紧急采取了以下措施：（1）降低performance.now()的精度（从5微秒降到100微秒甚至1毫秒）；（2）默认禁用SharedArrayBuffer（后来通过Cross-Origin-Isolation头重新启用）；（3）引入Site Isolation——将不同网站的内容放在不同的操作系统进程中，利用进程边界提供更强的隔离。Site Isolation的引入使Chrome浏览器的内存使用量增加了约10%–13%。
瞬态窗口的微架构快照。
要把Spectre v1从一段C代码的PoC升级为对微架构的深度理解，必须把"推测执行"还原到重排序缓冲区（ROB）、加载队列（LDQ）、MSHR（参见8.3.8 节）和发射队列（参见第 27.0 章）的联合快照上。关键事实是：当边界检查分支（BR）还在等待array1_size从DRAM返回时，依赖它的后续load已经被发射并执行完毕，它们在物理寄存器文件（PRF）中写回了结果，甚至已经让L1 Cache换入了攻击者关心的array2[secret*4096]这一行——只不过ROB还没走到它们的commit指针而已。图图 50.5给出了4条关键指令在瞬态窗口中的ROB快照。
这张快照反映的是现代乱序核心"投机唤醒+乱序发射+顺序提交"三者协作下的一种常见病态：发射队列的唤醒网络不区分spec_bit，只要tag匹配就立即唤醒消费者；LDQ在地址就绪后立即向L1发起访问，也不关心自己在ROB中的位置是否越过了一条尚未解析的分支。换言之，现代发射队列的设计目标（最大化ILP，参见第 27.0 章的wake-select循环）和Spectre v1的可利用性是同一个机制的两面。
周期级时序全景。
表表 50.4把同一个攻击实例按周期展开。请注意C50–C200之间的瞬态窗口：ROB头部被DRAM长尾钉住，但LDQ已经把两条投机load"跑完了"，L1里array2那一行的tag已经变了。C200分支结果返回触发squash，但Cache状态不在squash的作用域内。读表时要抓住三个时刻：C3（BR被分支预测器判定为taken，下游全部指令按照taken路径fetch+rename，BRMASK开始记录依赖）、C100–C200（secret已经写入PRF并被AGU消费，L1填充正在进行）、C210（BR源操作数就绪，ALU执行产生not taken结论，触发squash_bX信号）。C210到C250之间的squash不是"无代价"的——它会把ROB内约40条指令（瞬态窗口堆积）标记为无效、LDQ/SDQ对应条目清空，典型延迟7–15 cycle——但它不触及L1与MSHR历史。
| 时刻 | ROB head/tail | LDQ | L1 | MSHR | DRAM | BTB/PHT | spec信号 |
|---|---|---|---|---|---|---|---|
| C0 | #1 / #1 | LD1 alloc | miss on array1_size | MSHR[0]=sz addr | queued | PHT(BR)=T | – |
| C3 | #1 / #3 | LD1–BR–LD2 | – | MSHR[0] pending | issued | BR预测taken | spec=1 |
| C10 | #1 / #4 | +LD3 (array2) | array1 base hit | MSHR[0] pending | row open | – | spec=1 |
| C50 | #1 / #4 | LD2 exec完成 | LD2 hit array1[x] | – | row buffer hit | – | spec=1 |
| C100 | #1 / #4 | LD3 发射 | miss array2+R2*4K | MSHR[1]=arr2 | queued | – | spec=1 |
| C200 | #1 / #4 | LD3 完成,填L1 | array2行已驻留 | MSHR[1]释放 | array1_size返回 | PHT(BR)训练中 | spec=1 |
| C210 | #1 / #4 | – | – | – | – | BR算出NOT taken | mispredict! |
| C250 | #2 / #2 | LDQ[2..4] squash | array2行保留 | – | – | PHT回更 NT | spec=0 |
Spectre v1瞬态窗口的周期级状态表（单位：cycle）
为什么Cache不会被squash回滚。
squash逻辑（rename表回滚+ROB尾指针回退+LDQ/SDQ/发射队列清空）只恢复架构可见状态；L1的tag/data阵列、MSHR的历史填充记录、LRU伪年龄位、DRAM行缓冲区都属于微架构不可见状态，没有镜像备份也没有回滚通路。这正是瞬态执行攻击的统一根因：架构/微架构之间存在语义鸿沟。
具体地，squash信号在现代处理器中通常只向四处广播：（1）rename表与free list（回滚寄存器映射）；（2）ROB尾指针与各调度队列（清空尾部）；（3）IFU（重置PC到正确路径）；（4）分支预测器的历史寄存器（GHR/RAS回滚）。它不向L1、L2、DRAM控制器、MSHR历史、预取器置信度计数器、BTB/ITTAGE表项、TLB替换位广播——这些结构被刻意设计成"事务外"状态，正是为了避免每次误预测都拖慢Cache访问路径。Spectre v1把这个本意为"让误预测更便宜"的工程决策，反手变成了泄露通道。
推测唤醒下的load-load依赖链。
瞬态窗口内两条关键load的依赖关系尤其值得解剖。LD2（array1[x]）的结果R2通过写回总线广播tag=#R2，LD3（array2+R2*4K）的发射队列表项监听该tag；一旦tag匹配，LD3被wake-select逻辑选中，在next cycle通过AGU算出地址并立即访问dTLB+L1。在标准4-wide乱序核（如Intel Skylake、AMD Zen3）上，从LD2写回到LD3发起L1访问只需2–3个cycle——这是Spectre v1得以在单个DRAM长尾内完成"读secret→编码到cache"整个动作的基本原因。
更微妙的是：LD2自身可能来自L1 hit（array1是常用数组、L1中常驻），因此LD2的延迟短于分支解析延迟。这给Spectre v1提供了一个关键不变量——"secret在需要时总是就绪的"。如果LD2本身miss到L2/LLC，攻击者甚至可以在PoC中主动预热array1，保证瞬态窗口被array1_size的长尾主导，而不是被secret读取自身的延迟主导。这是PoC代码中常见的**CLFLUSH**+预热循环存在的真正原因，也是把问题从"控制推测"转移到"数据转发隔离"的直观证据。
spec_bit的传播与分支解析屏障。
图图 50.5里的spec_bit是一个极简的工程抽象。真实处理器通常在rename阶段给每条指令分配一个branch mask（BRMASK），用一个宽度等于in-flight分支数上限（如Skylake为48）的位向量记录"本指令依赖哪些尚未解析的分支"。每当一条BR进入ROB，它获得位向量中的一个独占位；后续所有rename的指令在其BRMASK中把置1。BR解析正确时广播"clear "信号，所有指令的BRMASK对应位清零；解析错误时广播"squash "信号，所有BRMASK对应位为1的指令被标记为无效并从尾部回退。
这个机制的代价是log(in-flight branches)级别的线数与CAM端口——正因如此，它覆盖控制依赖的回滚，而没有人愿意再付一套等量的代价去覆盖数据依赖的回滚（那需要跟踪"哪些PRF值来自投机load"并级联传播，代价接近taint tracking的硬件实现）。Spectre v1利用的正是这条"BRMASK只管控制，不管数据"的便宜抽象：LD3的地址数据是BR误预测路径上的产物，但该数据一旦写入L1 tag阵列，就脱离了BRMASK的管辖范围。ch51的STT方案将展示若要补上这个漏洞，硬件需要引入一套独立的"taint propagation网络"，其面积开销量级大致相当于再加一个BRMASK广播网络。
扩展瞬态窗口的工程手段。
攻击者并不总是被动接受200 cycle的DRAM长尾。实战PoC中常用三种手段主动放大：（1）把array1_size刻意放到一个LLC miss到DRAM的地址（通过**CLFLUSH**）甚至放到一个cross-socket远程内存上（NUMA延迟可达500–800 cycle）；（2）让该地址映射到一个正在被其他核写的共享cache line，从而经由MESI协议的转发/失效握手进一步拉长；（3）利用store-to-load forwarding失败（4K alias假阳性）制造额外的LDQ等待，顺便把邻近的投机load留在瞬态窗口中更久。这些手段都不改变Spectre v1的定性逻辑，但可以把瞬态窗口从200 cycle扩展到700–1000 cycle，让串行依赖链长度从66增长到300，从而把"秘密跳转+Flush+Reload探测"的全部依赖链都塞进单个窗口中（这也是为什么后续研究工作常把瞬态窗口建模为可延展的资源）。
性能分析 4 — Spectre v1瞬态窗口带宽理论上限
**Setup。**假设DRAM延迟 cycle（DDR4典型值），处理器4-wide发射，LDQ/STQ各64项，每条投机load的端到端延迟 cycle（L1 hit forwarding+地址生成）。瞬态窗口由array1_size的DRAM长尾决定： cycle。
Strategy（指令并行上限）。窗口内串行依赖链长度。即在单条secret-dependent load完成之前，我们至多能让66条相互数据依赖的load被投机发射。但Spectre v1只需要一条泄露load（LD array2[secret*4096]），窗口富余用于并行探测多个候选字节（256个候选cache line对应256条独立地址的load）。
另一条瓶颈来自ROB容量——瞬态窗口中分配出去的ROB条目一直不能retire（因为head被LD array1_size钉住），Skylake的ROB=224项，扣除LD1/BR/LD2/LD3及其填充指令之后，还能容纳约215条不相关的投机指令，所以ROB不是瓶颈；真正的硬约束是LDQ的64项与MSHR的10项左右，它们决定了瞬态窗口内能同时in-flight的load与未完成miss的数量上限。这意味着实战PoC会刻意控制投机load的数量不要超过MSHR容量，否则LD3会停在LDQ里等MSHR腾空，窗口白白流逝。
**Derivation（带宽推导）。**单字节泄露分两阶段：瞬态阶段注入并让L1留下痕迹，约 ns（@3 GHz）；探测阶段遍历256条探针cache line做Flush+Reload（参见50.2.1 节），每条探针200 ns命中判定，合计 ns s。加上分支预测器训练（参见13.4.2 节）——PHT 2-bit饱和计数器需要在mistraining循环中连续喂入1000轮让PHT锁死在strongly-taken，每轮50 s。单字节端到端恢复时间 ms。
**Interpretation。**理论带宽 B/s；但Kocher等人（2018）的原始PoC在Intel Haswell上实测达到约10 KB/s——差距来自：
256条探针可在同一次训练分摊中流水线化（同一窗口内泄露多位，而非只泄露1 bit）；
多个相邻字节可共享一次mistraining预热（同一段训练循环诱导后连续探测多个
x值）；使用**
CLFLUSH**替代eviction显式失效探针，使探测阶段从200 ns/line降到80 ns/line。
这三项乘法下来恰好把模型值从20 B/s拉到10 KB/s的量级，与Kocher实测一致。
**Verification。**把Spectre v1与Meltdown（后者实测503 KB/s）对比，50的带宽差异可完全归因于"每字节必须重训练PHT"这一额外成本——Meltdown无须训练分支预测器，它的瞬态窗口由异常处理流水线的长尾直接提供。该对比印证了本书的统一视角：攻击带宽的真正瓶颈不是瞬态窗口本身，而是建立瞬态窗口的预热开销。反过来看：如果处理器厂商要降低Spectre v1的实际危害，与其修复窗口内的信息流（昂贵），不如提高建立窗口的门槛（便宜且正交）——这也是后来ARM的SSBD（Speculative Store Bypass Disable）、Intel的PSFD等"限制特定投机形式"的防御思路所共享的工程直觉。
设计提示
**Spectre v1的真正微架构根因。**公众讨论常把责任归到"分支预测器"，但这个诊断是错位的。禁用分支预测不能修Spectre v1——只要还有任何投机形式（乱序、值预测、内存依赖预测、alias预测），攻击就可以换一种诱导方式复现；而禁用分支预测本身会让IPC损失70%以上，在工业上不可接受。真正的根因在数据通路的两个微小决策上：（a）投机load允许把读到的数据forward给后续load的地址计算，这使得secret从PRF走到AGU再走到L1 tag阵列的路径在spec_bit=1时仍然畅通；（b）L1/MSHR/替换策略都不感知spec_bit，使得该路径的副作用持久化。
因此Spectre v1的正确修法是在数据转发层面隔离投机，而不是在控制流层面屏蔽投机。ch51将讨论的STT（Speculative Taint Tracking，给可能来自投机load的数据打taint位，阻止它进入地址生成和分支条件）、NDA（No-speculative Data Access，更激进地延迟所有投机load）与前文的InvisiSpec（参见hw:ch50-invisispec，让投机load走影子缓冲）沿着三条不同路线实现"隔离推测load的数据转发"这一共同目标，各自的性能/面积权衡也将在那里展开。
从本书的统一视角再退一步看，Spectre v1揭示的是一条更一般的设计律：凡是"乐观地执行、错了再回滚"的微架构机制，都隐含一个"回滚是否完整"的安全前提。传统上这个前提靠ROB+rename+LDQ/SDQ三件套来保障，它们覆盖了所有架构可见状态；但一旦我们把某个结构从架构可见状态中剥离（Cache、TLB、BTB、预取器、替换位，都是这样被剥离出来的，正是为了让其性能可规模化），它就自动落在了回滚边界之外，也就自动成为新的侧信道候选。ch51会证明，STT/NDA/InvisiSpec本质上都在试图把这条边界重新画到合适的位置，但"合适的位置"在哪里，至今仍是活跃的研究问题。
Spectre v2（分支目标注入）
Spectre v2（CVE-2017-5715），也称为分支目标注入（Branch Target Injection, BTI），利用间接分支预测器（通常是BTB，Branch Target Buffer）将受害者的间接分支重定向到攻击者选择的gadget代码。
间接分支与BTB。间接分支指令（如x86的JMP [rax]、CALL [rax]，ARM的**BR x0）的跳转目标存储在寄存器中，在执行时才能确定。为了减少间接分支的流水线气泡，处理器使用BTB**（Branch Target Buffer）来预测间接分支的目标地址。BTB是一个以分支指令PC地址为索引的表，存储了每个分支上次跳转的目标地址。当一条间接分支被取指时，处理器在BTB中查找该分支的条目，并将预测的目标地址作为下一条指令的取指地址。
BTB中毒攻击。Spectre v2攻击的核心是BTB中毒（BTB poisoning）。攻击者在自己的代码中执行一条间接分支，使其PC地址在BTB中与受害者的间接分支发生别名（alias）——即两个不同的分支指令被BTB映射到同一个条目。攻击者将自己的间接分支的目标设置为一个精心选择的gadget地址（受害者地址空间中执行泄露操作的代码片段）。由于BTB的别名效应，当受害者执行其间接分支时，BTB返回攻击者注入的gadget地址，处理器推测性地跳转到gadget执行。
**BTB别名的原理。**BTB的索引通常使用分支指令PC的低位比特（例如低12位），不检查高位比特（或使用部分标签）。这意味着不同进程中PC低位相同的间接分支会映射到同一个BTB条目。攻击者可以通过在自己的虚拟地址空间中精心放置间接分支指令（使其虚拟地址的低位与受害者的间接分支相同），来实现BTB中毒。
攻击步骤。
（1）**Gadget发现。**攻击者分析受害者代码（如操作系统内核或共享库），寻找合适的gadget——一段在推测执行时能够读取秘密数据并通过Cache侧信道编码的代码。典型的gadget形如：temp = array[secret_value * 4096]，它将秘密值的某些位映射到Cache行的访问模式中。
（2）**BTB训练。**攻击者在自己的进程中，执行PC低位与受害者间接分支相同的间接跳转，目标为gadget的地址。重复执行多次以训练BTB。
（3）**触发受害者执行。**通过系统调用或其他方式使受害者（如内核）执行包含间接分支的代码路径。由于BTB已被攻击者训练为跳转到gadget，处理器推测性地执行gadget代码。
（4）**提取数据。**使用Flush+Reload或Prime+Probe检测gadget在推测执行期间造成的Cache状态变化，恢复秘密数据。
软件防御：Retpoline。Google工程师Paul Turner提出了Retpoline（return trampoline）技术来防御Spectre v2。Retpoline的核心思想是将所有间接跳转/调用替换为一种利用ret指令的"弹簧"结构，使得推测执行被困在一个无限循环中，永远不会到达攻击者指定的gadget。
具体来说，对于一条间接跳转JMP [rax]，Retpoline将其替换为：
call retpoline_target
retpoline_capture:
pause ; 推测执行被困在这里
jmp retpoline_capture
retpoline_target:
mov [rsp], rax ; 覆盖栈顶的返回地址为真实目标
ret ; 返回到rax指向的地址在这个序列中：（1）call指令将retpoline_capture的地址压入栈中并推入RSB（Return Stack Buffer）；（2）在retpoline_target处，用真实的跳转目标rax覆盖栈顶的返回地址；（3）ret指令使处理器根据RSB预测返回到retpoline_capture（因为RSB中记录的返回地址是call指令后面的地址），但实际执行时读取栈上已被修改的返回地址，跳转到正确的目标。推测执行被困在retpoline_capture的无限循环中，不会执行任何有用的gadget代码。
**硬件防御：IBRS和STIBP。**Intel在较新的处理器中引入了硬件防御机制：
（1）IBRS（Indirect Branch Restricted Speculation）：当IBRS启用时，低特权级代码（如用户态）的间接分支预测不能影响高特权级代码（如内核态）的间接分支预测。具体来说，进入内核态时处理器会隔离BTB的预测状态，使得用户态的BTB训练不会影响内核态的分支预测。
（2）STIBP（Single Thread Indirect Branch Predictors）：在SMT（超线程）处理器中，STIBP防止一个逻辑线程的间接分支预测影响同一物理核心上另一个逻辑线程的预测。
（3）eIBRS（Enhanced IBRS）：在更新的处理器（Ice Lake及之后）中，eIBRS提供了更全面的保护——处理器硬件确保间接分支预测器的状态在特权级切换和上下文切换时自动隔离，无需软件干预。
硬件描述 5 — BTB的安全设计考量
Spectre v2揭示了BTB设计中一个长期被忽视的安全问题：跨安全域的别名。传统BTB设计追求高命中率和低面积，使用PC的低位作为索引，可选地使用部分标签来减少别名率。然而，这种设计允许攻击者在同一BTB条目中注入恶意目标地址。
安全的BTB设计需要在以下几个维度加强隔离：
（1）PCID/VMID标签。在BTB条目中加入进程上下文标识（PCID）或虚拟机标识（VMID）标签，只有PCID/VMID匹配的条目才能命中。这可以防止不同进程/VM之间的BTB中毒。代价是增加每个BTB条目的存储（12–16位），但这在现代处理器中已经普遍实现。
（2）特权级标签。在BTB条目中记录训练时的特权级（如x86的CPL或ARM的EL），只有相同特权级的分支才能使用该条目的预测。这防止了用户态训练的BTB条目影响内核态的分支预测。Intel的eIBRS和ARM的CSV2在硬件中实现了这种隔离。
**（3）BTB刷新。**在安全域切换时（如用户态内核态），刷新BTB中所有可能被攻击者训练的条目。代价是域切换后的BTB冷启动会增加间接分支的缺失率和流水线气泡。Intel的IBPB（Indirect Branch Prediction Barrier）指令提供了这种功能，但由于性能代价较高（约2%–5%的IPC下降），通常只在进程上下文切换时使用，而不是在每次系统调用时使用。
从现象到微架构：深入 Spectre v2 的硬件根因
上文已经从攻击模型的角度说明了 BTB 中毒的基本流程，但要真正理解 Spectre v2 为什么在硬件上"天然"存在，必须走进 BTB 的索引电路、RSB 的循环栈结构以及分支历史寄存器的反馈路径。本节把前面对分支预测器的结构性铺垫（见第 第 13.0 章 章分支预测器基础和第 第 17.0 章 章中对 ITTAGE 等间接分支预测器的讨论）与50.3.1 节 中 Spectre v1 的瞬态执行窗口模型结合起来，逐层拆解 Intel Skylake/Ice Lake 一族中 BTB/RSB/BHB 的实现细节。
**BTB index hash 的微架构剖析。**以 Intel Skylake 为例，其一级间接分支预测器（IBP）大致包含一个约 4096 entry、4-way set-associative 的 BTB。索引宽度为 位，但 Skylake 实际使用的是对 VA 的"折叠 XOR"哈希：从虚拟地址 VA[47:2]（指令按 4 字节对齐，PC[1:0] 恒为 0）中抽取两个相邻的 10 位窗口，异或折叠成 10 位的 set index，其中高 9 位用于选 set，剩 1 位并入 way prediction。示意上，可把它写成 $$ 这种折叠的动机在第 第 17.0 章 章讨论 gshare/ITTAGE 时已经提到：XOR 折叠能让更多 PC 高位参与分桶，有效降低同一循环/函数内多条分支的冲突率，且 XOR 电路只有 1 级与门深度，几乎不影响取指关键路径。
然而，XOR 折叠带来的代价是跨高位地址的别名：只要两条分支指令的 VA[11:2] 与 VA[21:12] 的 XOR 和相等，它们就会落入同一个 set。攻击者从不需要物理上"冲撞" PC 低位，而是可以在自己可控的虚拟地址空间里，精心挑选满足上述等式的 jump gadget 地址。换言之，攻击者获得的是一条10 维线性方程形式的自由度，而不是硬性的 10 位前缀匹配。
![Skylake BTB 的折叠 XOR 索引示意：攻击者 VA 0x400\_ABCD 与受害者 VA 0x800\_ABCD 经过 \texttt{VA[11:2] $\oplus$ VA[21:12]} 后落入同一 set，way 由替换策略选中后即构成跨安全域别名。](/2030ProcessorDesign/figures/ch50-fig06.svg)
为什么 PCID/CR3 切换无法阻止 BTB 别名。直觉上，既然 x86 已经为 TLB 引入了 PCID（Process Context ID），那么 BTB 是否天然继承了这种隔离？答案是否定的——在 Skylake 时代的 BTB 条目中没有 context tag。这是一个纯粹的面积/时序权衡：BTB 需要在取指的第一周期就给出预测目标以填充 BPU 队列，任何额外比较（如 12 bit PCID tag）都会挤压 fanout/比较器的时序预算；而 BTB 即使偶尔给出错误的目标也"只是"造成一次流水线刷新，与 TLB 给出错误的物理地址引发的一致性灾难不可同日而语。结果是：MOV CR3 切换进程后，TLB 可以按 PCID 保留条目，但 BTB 既不刷新也不打 tag，旧进程遗留下的预测记录原封不动地留给新进程"用"——Spectre v2 的别名攻击在硬件语义上是被允许的副作用，而不是一个可以通过简单补丁撤销的 bug。
RSB 下溢与 Retbleed 的硬件根因
**RSB 的硬件结构。**Return Stack Buffer 是一个与主 BTB 解耦的小型循环栈，典型容量为 16 entry（Intel Skylake/Cascade Lake/Ice Lake 均如此，AMD Zen 系列为 32 entry 并采用双线程独立切片）。每次前端解码到 CALL 时，将该 CALL 的返回地址压入 RSB；每次解码到 RET 时，从 RSB 顶部弹出并作为预测目标送入 Fetch。由于 RSB 是循环栈，当指针走过第 16 个槽时会回绕覆盖最早的条目——这意味着一旦函数调用深度超过 16 层，早期的返回地址就永远无法被 RSB 准确预测。
下溢的危险路径。真正危险的场景是 RET 数多于 CALL 数：比如 VMEXIT 从 guest 陷入 hypervisor 时，硬件会清空（或实际上清空性覆盖）RSB；或是 longjmp、setjmp、异常展开这类不对称控制流；或是纯粹因为长调用链上溢过 16 层后回退到较浅层的 RET。此时 RSB 为空或被 stale 条目污染，预测器必须回答一个问题：ret 的目标该交给谁预测？
Intel Skylake/Cascade Lake/Ice Lake 之前的实现：RSB 空即回退到 BTB，把
RET当作普通间接分支查表预测。这正是 Retbleed (CVE-2022-29900/29901) 的根源：攻击者可以像训练普通间接分支一样训练 BTB 里对应RETPC 的条目，一旦内核走到 RSB 下溢的RET，就被劫持到攻击者指定 gadget。AMD Zen 1/2 的设计：RSB 空时不发出推测预测，直接 stall 前端。理论上这应该免疫 Retbleed 的"BTB-as-RET-fallback" 变种，但 Zen 仍在 2022 年被发现存在 Retbleed 风险——原因不在 RSB 下溢本身，而在 AMD 的非条件化
RET推测行为（对应的 ENVH 与后续 Inception 攻击面，将在第 51.0 章 中讨论硬件侧防御时回到）。
BHI：eIBRS 之上的"最后一英里"
**背景设定。**从 Ice Lake 开始，Intel 引入 eIBRS 以期在硬件层面阻止跨特权级的 BTB 污染（见本章 hw:ch50-btb-security）。eIBRS 的核心承诺是：用户态训练的 BTB 条目，进入内核后不会被命中。那么 Spectre v2 是否就此终结？2022 年公开的 BHI（Branch History Injection，CVE-2022-0001/0002，又称 Spectre-BHB）证明没有。
BHB 的结构性遗漏。Intel 的 IBP 并不是仅以 PC 为索引——它还使用一个约 194 bit（内部组织细节保密，但公开分析显示至少 88 bit 全局历史寄存器 + 其余路径哈希片段）的分支历史缓冲区（Branch History Buffer，BHB）参与 BTB set 索引与 way hash。BHB 在每次条件/间接分支后更新：通常是BHB (BHBk) H(target_PC)形式的线性反馈。eIBRS 只为 BTB 条目打上特权级/VMX root 标签，阻止"匹配但来自错误特权级"的命中；而 BHB 寄存器本身在 ring 0 ring 3 切换时不清零、不隔离——它承载的是整条历史轨迹，被视为"预测质量"而非"安全资产"。
**攻击构造。**于是 BHI 的攻击路径形如：（i）攻击者在用户态执行一段精心构造的分支序列，使 BHB 被"染色"为某个特定值 ；（ii）触发 syscall 进入内核；（iii）内核执行到目标间接分支（如 call *%rax）；（iv）BTB 以 {PC, BHB=} 作为 set/way 索引，命中攻击者此前在用户态同 下以同 PC 训练出的条目（eIBRS 要求 PC 和特权级匹配，但攻击者可以在自己地址空间中以用户态特权级用同 PC 训练，只要 BTB 按 way 的 retention 策略仍保留了那个条目，或者借助 lower-half alias；研究者已证实多种命中路径）；（v）推测执行跳到 gadget。
**防御：BHB Clear。修复的根本方法是在每次特权级转换（syscall/VMEXIT）后，由硬件或软件强制清空 BHB。Intel 通过微码下发了BHB_CLEAR**等价序列（一段精心设计的、会让 BHB 反馈电路收敛到全零不动点的分支流），Linux 内核从 5.17 起在 syscall 入口显式调用该序列。其硬件实现细节——包括为什么"清零"不能简单接地而要走若干轮反馈、以及在 Sapphire Rapids 之后的原生 IA32_SPEC_CTRL.BHI_DIS_S 位——将在 第 51.0 章 的防御机制章节中详细展开。
**性能影响。BHB_CLEAR**每次 syscall 增加约 30–60 cycles，对典型系统调用密集负载（nginx、redis）的 IPC 影响约 1%，与 KPTI 相比接近忽略不计。真正的代价在于清空 BHB 后的前几十条分支会损失历史上下文，预测精度短暂下降——这再次呼应了第 第 17.0 章 章关于"预测器状态是性能资产"的观察。
一个简化的、带别名漏洞的 BTB 实现
为了把上述微架构细节落到可综合的 RTL 视角，下面给出一个刻意简化的 2-way BTB 模块。它复刻了 Skylake 折叠 XOR 索引的本质结构，也刻意保留了没有 security tag 这个漏洞——这正是 Spectre v2 别名攻击得以存在的根源。
// 简化 BTB：2-way set-associative, 512 sets, 折叠 XOR 索引
// 注意：这是一个"故意不安全"的参考实现，用于解释 Spectre v2 的硬件根因
module btb_vulnerable #(
parameter int SETS = 512,
parameter int WAYS = 2,
parameter int TARGET_W= 48
) (
input logic clk,
input logic rst_n,
// 预测端口
input logic [63:0] fetch_pc,
output logic [TARGET_W-1:0] predict_target,
output logic predict_valid,
// 更新端口（retire 时回写）
input logic update_en,
input logic [63:0] update_pc,
input logic [TARGET_W-1:0] update_target
);
// 存储阵列：target + valid + 简化的 2-bit tag（仅 PC[22:21]，不含 PCID、不含 CPL）
logic [TARGET_W-1:0] target_mem [SETS][WAYS];
logic valid_mem [SETS][WAYS];
logic [1:0] tag_mem [SETS][WAYS];
// 折叠 XOR 索引：对齐 Skylake 的 VA[11:2] ^ VA[21:12]
function automatic [8:0] hash_idx(input [63:0] pc);
hash_idx = pc[11:2] ^ pc[21:12]; // TODO(secure): 混入 PCID/ASID
endfunction
logic [8:0] idx_r;
logic [1:0] tag_r;
always_comb begin
idx_r = hash_idx(fetch_pc);
tag_r = fetch_pc[22:21];
end
// 读路径：way 比较并选 hit
logic way0_hit, way1_hit;
always_comb begin
way0_hit = valid_mem[idx_r][0] && (tag_mem[idx_r][0] == tag_r);
way1_hit = valid_mem[idx_r][1] && (tag_mem[idx_r][1] == tag_r);
predict_valid = way0_hit | way1_hit;
predict_target = way0_hit ? target_mem[idx_r][0] : target_mem[idx_r][1];
end
// 写路径：简化的伪 LRU，实际 Skylake 使用 Tree-PLRU
logic lru_bit [SETS];
always_ff @(posedge clk or negedge rst_n) begin
if (!rst_n) begin
for (int s = 0; s < SETS; s++) begin
valid_mem[s][0] <= 1'b0;
valid_mem[s][1] <= 1'b0;
lru_bit[s] <= 1'b0;
end
end else if (update_en) begin
automatic logic [8:0] uidx = hash_idx(update_pc);
automatic logic [1:0] utag = update_pc[22:21];
// 刻意缺失的安全检查：
// TODO(secure): 检查 update_priv_level == current_priv_level
// TODO(secure): 检查 update_pcid == current_pcid
// TODO(secure): 混入 VMID 以防跨 VM 污染
// 没有这些检查，任何特权级、任何进程都能训练任何条目 → Spectre v2
target_mem[uidx][lru_bit[uidx]] <= update_target;
tag_mem [uidx][lru_bit[uidx]] <= utag;
valid_mem [uidx][lru_bit[uidx]] <= 1'b1;
lru_bit[uidx] <= ~lru_bit[uidx];
end
end
endmodule代码层面的危险三件套已经藏在注释里：（i）索引函数 hash_idx 只看 PC，没有混入 ASID/PCID，跨进程自然别名；（ii）更新端口 update_en 没有校验当前特权级，用户态 retire 的间接分支会直接写入内核路径上同 set 的条目；（iii）2 bit tag 仅取 PC[22:21]，不含任何安全上下文——这是把 BTB 当作"性能结构"而不是"安全结构"来设计的典型化石。修复方式——在硬件中新增 PCID/VMID/CPL tag、在切换时主动 invalidate 或启用 eIBRS 的按 tag 过滤——都属于下一章的范畴。
小结与前向桥接
Spectre v2 在硬件上是三重设计假设的叠加产物：BTB 索引为了面积/时序选择了无 tag 的 XOR 折叠；RSB 下溢为了性能选择了回退到 BTB；BHB 为了预测精度选择了跨特权级保留历史。任何单独的修复都只是堵上其中一个缝隙，真正的解法必须把"安全域"作为 first-class 的硬件概念带进分支预测器的每一个表项、每一个索引函数、每一次更新端口。下一章 第 51.0 章 将从 IBPB、eIBRS 到 BHB Clear 逐一展开这些硬件防御的实现细节，其中 §7.2 会集中讲解 BHB Clear 反馈电路如何在不增加前端关键路径延迟的前提下清空 194 bit 历史状态。
Meltdown（熔断）
Meltdown（CVE-2017-5754）是与Spectre同时披露但攻击原理完全不同的漏洞。Meltdown利用的不是分支预测器，而是处理器在乱序执行中对权限检查的延迟处理。
正常的内存保护机制。在现代操作系统中，用户态程序不能直接读取内核内存。这种保护通过页表中的权限位实现：内核页面的User/Supervisor位设置为Supervisor，当用户态代码试图访问这些页面时，MMU（Memory Management Unit）会产生一个页面错误（page fault）异常。
**Meltdown的攻击原理。**在存在Meltdown漏洞的处理器（主要是Intel Core系列处理器，以及部分ARM Cortex-A系列）中，当用户态代码执行一条访问内核内存的load指令时：
（1）处理器的乱序执行引擎首先执行load指令，从Cache（或内存）中获取内核数据。由于现代处理器中TLB查找和Cache查找通常并行进行，处理器可能在权限检查完成之前就获得了数据。
（2）权限检查的结果（页面错误）需要等到load指令到达ROB头部准备提交时才被处理。在此之前，已读取的内核数据可以被后续的乱序指令使用。
（3）攻击者构造的后续指令将内核数据通过Cache侧信道编码（类似Spectre中的array2[secret * 4096]）。
（4）当页面错误最终被处理时，处理器撤销load及其后续指令的架构效果，但Cache中的编码数据已经泄露。
Meltdown的乱序执行利用机制
Meltdown攻击的核心在于利用乱序执行引擎中权限检查与数据转发的时序竞争。让我们从处理器微架构的角度详细分析这个过程。
在一个典型的乱序处理器中，一条load指令的执行经过以下步骤：
地址生成：AGU（Address Generation Unit）计算load的目标虚拟地址。
TLB查找：将虚拟地址送入TLB，查找物理地址和权限信息（包括User/Supervisor位、Read/Write/Execute位）。
Cache查找：（与TLB查找并行或在TLB完成后）使用物理地址在L1D Cache中查找数据。
权限检查：TLB返回的权限信息被检查——如果当前特权级不满足要求（如用户态访问Supervisor页面），标记该load为"异常待处理"。
数据转发：如果Cache命中，将数据写入物理寄存器并唤醒依赖指令。
异常处理：当load到达ROB头部准备提交时，如果有"异常待处理"标记，触发页面错误异常。
Meltdown漏洞存在于步骤4和步骤5之间的时序关系。在受漏洞影响的Intel处理器中，步骤5（数据转发）在步骤4（权限检查）之前或同时发生——即使权限检查最终失败，数据已经被转发给了后续的依赖指令。在步骤6处理异常时，虽然load及其后续指令的架构效果被撤销，但这些指令在乱序执行期间造成的Cache状态变化（微架构副作用）不会被回退。
Meltdown PoC的攻击核心代码可以用以下伪代码表示：
// 攻击者在用户态执行
uint8_t probe_array[256 * 4096];
// 步骤1：尝试读取内核地址（会触发page fault）
uint8_t kernel_byte = *(uint8_t*)KERNEL_ADDRESS; // 触发异常
// 步骤2：将内核字节值编码到Cache中（推测执行/乱序执行）
volatile uint8_t dummy = probe_array[kernel_byte * 4096];
// 步骤3：异常被处理后，通过信号处理器恢复执行
// 然后探测probe_array找出哪个页面在Cache中
for (int i = 0; i < 256; i++) {
if (is_cached(&probe_array[i * 4096])) {
printf("Kernel byte = %d\n", i);
}
}实际的Meltdown PoC需要处理page fault异常——攻击者使用signal(SIGSEGV, handler)注册异常处理器，或者使用Intel TSX（Transactional Synchronous Extensions）来抑制异常（TSX在事务中遇到异常时不触发操作系统异常处理，而是静默地中止事务并跳转到回退路径）。TSX方法更加高效，因为避免了操作系统异常处理的数千周期开销。
**乱序执行窗口的大小。**Meltdown攻击的成功率取决于在异常被处理之前，推测/乱序执行能够执行多少条"泄露"指令。在典型的Intel处理器中：
如果内核数据在L1 Cache中命中（约4周期），乱序执行窗口约为ROB深度（200300条指令）减去从load到提交的流水线延迟（1020周期），足够执行数十条后续指令。
如果内核数据需要从L2/L3 Cache中加载（1040周期），窗口更大，因为异常处理需要等待load完成。
如果内核数据不在任何Cache中（需要从DRAM加载，200+周期），异常的处理会更加延迟，但乱序执行也可能因为load数据尚未返回而无法执行后续的编码操作——此时攻击成功率下降。
性能分析 5 — Meltdown攻击的信息泄露速率
在实际测试中（Intel Core i7-7700, Kaby Lake），Meltdown攻击的典型性能指标如下：
单字节泄露延迟：约5005000个时钟周期（取决于目标数据是否在Cache中）
信息泄露速率：约500 KB/s 2 MB/s（内核数据在L1/L2 Cache中时最快）
成功率：单次尝试约8595%，通过重复采样和多数表决可提升到99%
攻击范围：可以读取整个内核地址空间，包括内核代码、内核数据、DMA缓冲区和其他进程通过内核映射的内存
Meltdown的泄露速率远高于Spectre v1（后者受限于分支预测器训练的开销），这使得Meltdown在实际攻击场景中更加危险——攻击者可以在短时间内导出大量的内核内存数据。
Meltdown与Spectre的本质区别。Meltdown利用的是乱序执行引擎对异常的延迟处理——处理器在检查权限之前就让数据可用于后续指令。Spectre利用的是分支预测器的误训练——处理器在分支方向错误的情况下推测执行代码。两者的共同点是都利用了推测/瞬态执行的微架构副作用（主要是Cache状态变化）来泄露数据。
**Meltdown的影响范围。**Meltdown主要影响Intel处理器（从2008年的Core微架构到2018年的Coffee Lake），因为Intel的乱序执行引擎在权限检查完成前就允许后续指令使用load的结果。AMD的处理器在架构上不存在Meltdown漏洞——AMD的load单元在权限检查失败时不会将数据转发给依赖指令（而是转发零或触发异常），阻断了数据泄露路径。ARM的情况较为复杂，部分高性能核心（如Cortex-A75）受影响，而较简单的核心不受影响。
软件防御：KPTI/KAISER。在Meltdown公开之前，Gruss等人在2017年提出了KAISER（Kernel Address Isolation to have Side-channels Efficiently Removed）方案，后来被Linux内核采纳为KPTI（Kernel Page Table Isolation）。KPTI的核心思想是为每个进程维护两套页表：
（1）用户态页表：只映射用户空间的内存和极少量的内核入口/出口代码（trampoline），不映射内核的其余部分。这样即使Meltdown漏洞存在，用户态的load指令也无法从TLB/Cache中获取内核数据——因为内核页面根本不在用户态页表中。
（2）内核态页表：映射整个地址空间（用户空间+内核空间），在内核态执行时使用。
每次用户态内核态切换时，都需要切换CR3寄存器（x86的页表基地址寄存器）来加载不同的页表，并刷新TLB中可能包含旧映射的条目。这导致了显著的性能开销：
性能分析 6 — KPTI的性能代价
KPTI引入的性能开销主要来自两个方面：
**（1）页表切换开销。**每次系统调用（syscall）和中断处理都需要切换CR3（约20–30个周期），并在返回用户态时再次切换回来。
**（2）TLB失效开销。**页表切换后，TLB中缓存的旧页表的翻译条目不再有效。如果处理器支持PCID（Process Context ID），可以用不同的PCID区分两套页表的TLB条目，避免完全刷新TLB，但仍然会增加TLB的有效容量压力（TLB需要同时缓存两套页表的条目）。
| 工作负载类型 | 无PCID的性能损失 | 有PCID的性能损失 |
|---|---|---|
| 系统调用密集型（如Redis） | 15%–30% | 5%–10% |
| I/O密集型（如数据库） | 10%–20% | 3%–7% |
| 计算密集型（如HPC） | 1% | 0.5% |
| 混合工作负载（如Web服务器） | 5%–15% | 2%–5% |
从表中可以看出，KPTI对系统调用密集型工作负载的影响最大。这是因为这类工作负载频繁地在用户态和内核态之间切换，每次切换都需要页表替换和可能的TLB失效。PCID的使用可以显著减少开销，因此现代处理器（Skylake及以后）对PCID的支持对于降低KPTI的性能代价至关重要。
**硬件修复。**从2019年的Ice Lake开始，Intel在硬件中修复了Meltdown漏洞。具体做法是：当load单元检测到权限违规时，立即抑制将加载的数据转发给依赖指令（将转发的值置为零），而不是等到提交阶段才处理异常。这在微架构上只需要在load单元的数据转发路径中加入权限检查逻辑，对正常执行的性能几乎没有影响（权限检查与数据读取并行进行）。有了这个硬件修复后，KPTI对于Meltdown防御不再必要（但KPTI仍然对防御某些其他攻击有价值）。
设计提示
Meltdown的根本教训是：处理器的乱序执行引擎在处理安全检查时不能"先斩后奏"。传统的乱序设计中，异常被视为"稀有事件"，其处理被推迟到提交阶段以简化乱序执行逻辑。这种设计在功能正确性上没有问题（异常总是会在提交时被正确处理），但在安全性上存在漏洞（异常触发前的数据已被泄露到微架构状态中）。
安全的设计原则是：对于涉及安全边界的检查（如权限检查、边界检查），结果必须在数据被后续指令使用之前就可用。这可以通过以下方式实现：（1）在load单元中集成快速权限检查逻辑，与Cache访问并行执行；（2）在数据转发路径中添加门控逻辑，只有权限检查通过后才允许数据被转发；（3）对于推测执行的load，在权限检查完成前用零值或随机值替代真实数据。
硬件描述 6 — P6 load 单元的权限检查通路延迟分解
基于 Intel Optimization Reference Manual 与 Agner Fog 的微架构分析，P6 族（包括 Haswell/Skylake）的 load 单元延迟分解如下：
| 阶段 | 延迟（cycle） | 输出 |
|---|---|---|
| AGU 地址生成 | 1 | 线性地址 |
| TLB lookup（并行于 L1D tag） | 1 | 物理地址 + 权限位 |
| L1D tag 比较 + data array 读出 | 4 | load 数据（可 forward） |
| 权限比较（U/S, NX, R/W vs CPL） | 2（TLB 之后） | 异常信号（若违规） |
| ROB 异常提交与 pipeline flush | 数百 cycle | 架构级异常 |
关键观察：load 数据在第 cycle 即已进入 forward 网络，而权限违规信号要到第 cycle 才产生，再加上信号从 TLB 传回 ROB 的 1–2 cycle 布线延迟，权限违规的抑制信号到达 forward 网络时，数据已经 forward 出去约 – cycle。这 10–15 cycle 就是 Meltdown 的瞬态窗口——足够 OoO 引擎连续发射若干条依赖该数据的 probe 指令并污染 L1D。
这个设计在 1995 年看来是完全合理的：权限违规被视为稀有事件（well-behaved program 几乎不会触发），为稀有事件付出 load-use 延迟增加 1 cycle 的代价是不划算的——在 SPEC CPU 上，load-use 延迟每增加 1 cycle，整数性能损失约 3%–5%。P6 的设计者 Fred Pollack 的团队做出了"异常在 ROB 提交时再处理"的工程权衡，这在架构可见行为上是完美的（异常总会正确抛出），但 23 年后才被发现在微架构副作用上是漏洞。这也解释了为什么 Meltdown 从 Pentium Pro 到 Kaby Lake 一路延续——它不是某一代的 bug，而是 P6 家族的架构胎记。
为什么 AMD K8 系列免疫：一个鲜为人知的设计差异
Meltdown 披露时最令人惊讶的事实之一是：AMD 的所有 K8 及之后的处理器（Athlon 64、Phenom、Bulldozer、Zen 系列）都对 Meltdown 免疫。这不是因为 AMD 的 load 单元更慢，也不是因为 AMD 做了额外的权限检查——而是 AMD 在 K8（2003 年）设计时就做出了一个不同的工程选择：L1D 的 data forward 被 TLB 权限位 gating。
具体来说，AMD K8 的 load 单元设计采用 permission-aware forwarding：TLB 在返回物理地址的同时，将权限位与 CPL 比较的结果作为 gating 信号送入 L1D 数据通路。L1D 的 tag 比较可以推测性进行（这部分与 Intel 相同），但data forward 的 enable 信号是权限比较结果的 AND——如果权限不通过，forward 网络不会驱动数据总线，或者驱动一个零值。这个设计多出的逻辑仅是 L1D forward 仲裁器前的一个 AND 门，其延迟被隐藏在 L1D 的 ECC 检测电路的关键路径中（ECC 的 syndrome 计算本来就需要 1–2 cycle），因此没有增加 load-use 延迟。
历史考证方面有一个耐人寻味的事实：AMD 的工程师 Mike Clark 在 2018 年 Meltdown 披露后公开承认，AMD 内部在 K7/K8 设计时期就意识到权限违规的 load 可能泄露微架构状态——但当时认为这"只是一个性能/安全的次级权衡"，而没有将其披露为漏洞。AMD 选择在电路层面修复它，Intel 选择将风险推迟到"稀有事件处理"。两种工程哲学的分歧，酝酿出了 15 年后的行业大事件。
设计提示
Meltdown 免疫 整体更安全。AMD 处理器对 Spectre v1/v2 同样脆弱——因为 Spectre 利用的是推测控制流（分支预测器训练），而 Meltdown 利用的是推测数据流（跨权限 load 的 forward）。两者的根因属于不同的微架构子系统：Spectre 在 BPU/BTB，Meltdown 在 load 单元的 permission gating。"AMD 比 Intel 安全"是一个以偏概全的说法——准确的表述是："AMD 的 load 单元恰好没有 Meltdown 家族漏洞"。
Foreshadow 与 L1TF：攻破 SGX 硬件飞地
如果说 Meltdown 揭示了"权限检查太晚"的问题，那么 2018 年 8 月披露的 Foreshadow（Van Bulck 等，USENIX Security 2018）与 Intel 同期命名的 L1TF（L1 Terminal Fault，CVE-2018-3615/3620/3646）就把同一类问题推向了更深的层次——它们揭示了 Intel L1D 在页表项不存在（PTE.Present 0）时的行为仍然是可以被利用的。
要理解 L1TF，必须理解 Terminal Fault 的定义。在 x86 的 page walk 过程中，如果 MMU 在某一级页表中读到 Present 0 的 PTE，理论上应当立即终止 walk，将该 load 标记为 page fault，并不在 cache 中留下任何副作用。这是 Intel SDM 明确规定的架构行为。然而，微架构上 Intel 的 load 单元在 Present bit clear 时做了一件令人惊讶的事：它仍然取用 PTE 中剩余的 40 位物理页框号（PFN）字段，作为 L1D tag 比较的候选物理地址！
硬件描述 7 — L1D Terminal Fault 的数据通路
在 Intel Skylake/Kaby Lake 的 load 单元中：
Page walker 读到 PTE，发现 Present 0。
Walker 本应丢弃整个 PTE 内容并将 load 标记为 fault。
但微架构优化：walker 已经把 PTE 的 bits [51:12]（PFN 字段）送入 L1D 的 tag 比较寄存器——这个动作发生在 Present bit 被检查之前。
L1D 用这个"虚构的物理地址"进行 tag 比较。如果 L1D 中恰好有一条 cache line 的 tag 匹配该 PFN，数据会被 forward 给依赖 μop——完全忽略了 Present 0 这一事实。
异常（page fault）在 ROB 提交阶段才处理，与 Meltdown 同构。
关键矛盾：PTE 的 Present 字段与 PFN 字段在同一个 64 位字中，但两者的消费者不同——Present 被 walker 的控制逻辑消费，PFN 被 L1D 的数据通路消费。两路信号未做互锁（interlock），导致"Present 0 但 PFN 仍被使用"的畸形状态。这个 bug 是路径切分（path decomposition）优化的副作用。
SGX 的承诺被击穿。L1TF 最震撼之处在于它攻破了 Intel SGX（Software Guard eXtensions）。SGX 的核心安全承诺是：即使操作系统/Hypervisor 被完全攻陷，enclave 内部的秘密（包括用于远程证明的 EPID 私钥）也无法泄露——硬件内存加密引擎（MEE）确保 enclave 页面在 DRAM 中是密文。但 Foreshadow 发现：enclave 数据进入 L1D 时是明文（否则无法计算），而 L1TF 允许任意用户通过构造恶意 PTE 来读取 L1D 中任意地址的明文数据。
案例研究 3 — Foreshadow 对 Intel SGX 远程证明的毁灭性打击
Van Bulck 等人的 PoC 演示了以下完整攻击链：
在自己拥有的进程中分配一段虚拟地址空间 。
修改 对应的 PTE：清 Present 位，将 PFN 字段填入目标 enclave 的物理页帧号（通过
/proc/self/pagemap或其他侧信道预先获知）。让 enclave 做一次签名操作——这会把 EPID 私钥短暂加载到 L1D。
攻击者进程访问 。触发 L1TF，L1D 按 enclave PA 做 tag 比较，命中，数据 forward 到瞬态 μop。
Flush+Reload（见 50.2.1 节）逐字节泄露 EPID 私钥。
后果：攻击者获得 Intel IAS（Intel Attestation Service）认可的 EPID 私钥，可以伪造任意 enclave 的远程证明。这意味着对手可以让一个完全被控制的机器向银行、DRM 服务声称"我是正品 SGX enclave，里面的代码是审计过的"。Intel 不得不撤销全部老款 CPU 的 EPID 证书，并对所有启用 SGX 的系统推送微码更新，引入"TCB recovery"流程——这是 Intel 有史以来最大规模的硬件信任链回撤事件。
Intel 的紧急缓解措施代价极高。微码更新引入了以下机制：（1）L1D flush on VMENTER/VMEXIT——每次虚拟机进出都清空整个 L1D（32 KB 的 data array 写入周期约 350 cycle）；（2）L1D flush on SGX EENTER/EEXIT；（3）SMT 禁用或 core scheduling（见下节）。据 Phoronix 2018 年 8 月的基准测试，开启全部 L1TF 缓解后，PostgreSQL pgbench 在 Xeon Gold 6154 上下降 18%–22%；Redis 下降约 8%；Java 应用服务器（Tomcat + Spring）下降约 12%——这还不包括 SMT 禁用的额外开销。
L1TF 穿透 EPT：虚拟化信任边界崩塌
L1TF 的破坏力远不止 SGX。同样的"Present 0 但 PFN 仍被使用"问题，在扩展页表（EPT）——Intel VT-x 的二级地址转换机制——中以更可怕的形式出现。
在虚拟化环境下，page walk 是嵌套的：guest 的 GVA GPA 通过 guest 页表翻译，GPA HPA 再通过 EPT 翻译。EPT 的叶子 PTE 同样有一个 Present 位（Intel 称之为 "R/W/X" permissions 的组合——全 0 表示"不可访问"）和一个 HPA 字段。L1TF 漏洞意味着：恶意的 guest 如果能控制自己在 host 中的 EPT 叶 PTE（注意：正常情况下 guest 无法直接写 EPT，这是 hypervisor 的职责），就能读取 host 的任意 L1D 内容。
攻击者如何影响 EPT PTE？答案藏在 EPT 的惰性分配与交换机制中。当 hypervisor 把一个 guest 页面 swap 出 host 物理内存时，它会把 EPT 中对应的叶 PTE 清零（Present 0）——但是 Xen、KVM 在某些版本中保留了 HPA 字段以便后续 swap-in。攻击者只需让 hypervisor 触发自己页面的 swap-out，就能获得一个"Present 0 但 HPA 指向 host 物理内存"的 EPT PTE。然后访问对应的 GVA L1TF 触发 读取到 host 物理内存的 L1D 内容。
案例研究 4 — L1TF 与云计算行业的紧急停摆
2018 年 8 月 14 日 Foreshadow 公开披露，几乎所有主流云厂商在 24 小时内发布紧急公告：
AWS：EC2 宿主机全部部署 L1D flush + 禁用
-mno-indirect-branch-cpy优化；部分专用实例类型（m4、c4）临时降级为单 SMT。Azure：Hyper-V 引入 "core scheduling"——确保同一物理核心上的两个 SMT 线程只运行来自同一个 VM 的 vCPU，防止跨 VM 的 L1D 污染。
Google Cloud：GCE 禁用 SMT 默认启用；使用专用物理主机的 Confidential VMs 提前退休了 Skylake-SP，优先部署 AMD EPYC。
Kubernetes：启用 L1TF 缓解后，宿主机的可调度 Pod 密度下降 25%–30%——因为禁用 SMT 等效于核数减半，且核心调度让某些 slot 空闲。阿里云与腾讯云都在 2018 年底发布了"专有物理核"定价档，把 L1TF 的成本传导给客户。
长期影响：L1TF 成为 Intel 在云原生时代的战略转折点——AWS Graviton（ARM）项目加速、微软 Azure 加大 AMD EPYC 采购、Google 自研 Tensor/Axion 芯片——多云厂商开始系统性地 diversify away from Intel x86。2019–2022 年 Intel 数据中心市场份额的快速下滑，Foreshadow/L1TF 是重要推手之一。
Meltdown 泄露带宽的理论推导
性能分析 7 — Meltdown 泄露带宽的五步推导
[Setup] 目标平台：Intel Xeon E5-2680 v3（Haswell-EP，2.5 GHz，L1D 32 KB/32-set/8-way，L1D flush 约 350 cycle）。瞬态窗口 cycle（ROB 容量 192 μop，Haswell 宽 4-issue，异常提交延迟约 cycle）。单次 L1 访问 cycle，Flush+Reload 的 miss 延迟 cycle。
[Strategy] Meltdown 的每轮攻击泄露一个字节（8 bit）。策略是：在瞬态窗口内发射 1 条越权 load 1 条用 load 值做 index 的 probe load（访问 probe[secret * 4096]，4096 = 64 cache line 64 B 避开 prefetcher）。完成后用 Flush+Reload 扫描 probe 数组的 256 个槽位，找出被载入 L1D 的那一个。
[Derivation] $$\begin{aligned} t_{\text{probe-one-byte}} &= \underbrace{t_{\text{flush}}}{\approx 256 \times 70 \text{ns}} + \underbrace{t{\text{transient}}}{100 \text{ns}} + \underbrace{t{\text{reload}}}{256 \times (t \text{ or } t_{miss})} \ &\approx 17{,}900 \text{ns} + 100 \text{ns} + 256 \times 120 \text{ns} \ &\approx 17.9 + 0.1 + 30.7 \approx 49 \text{ μs} \end{aligned}$$ 朴素估算带宽 。但考虑到噪声 + 重试（平均 2–3 次才能稳定读出一字节），实际带宽约 。
[Interpretation] Lipp 等（USENIX Security 2018）实测 503 KB/s——比朴素推导高 50–100 倍！差距来源是：
TSX 取代 signal handler：用
XBEGIN/XABORT抑制异常，省去 OS 信号处理的 5000 cycle 开销；批量探测：在一个 TSX 事务里连续读多个字节，均摊 flush 成本；
L3-set 位并行：利用 probe 数组与受害者数据共享 L3 set 的行为，单次 reload 可同时得到多 bit 信息。
[Verification] 为什么 Meltdown 比 Spectre v1 快 ？Spectre v1 需要训练 PHT（通常 次分支历史注入才能让分支预测器稳定误判），每次训练约 cycle，共 50 μs/字节纯训练成本。Meltdown 不需要训练——它直接使用 fault-suppression 触发瞬态窗口，节省的正是这笔训练开销。这也解释了为什么 Meltdown 一经披露就被认为"比 Spectre 更紧迫"——它的利用门槛与带宽都远优于 Spectre v1。
设计权衡 2 — Meltdown 硬件修复的三种路线
Intel 与业界对 Meltdown 的硬件修复路线有三种：
零值替代（Ice Lake 采用）：load 单元检测到权限违规时立即将 forward 数据替换为 0，保留 forward 时序不变。代价：在 L1D forward mux 前增加一级 AND-gate，关键路径 逻辑级，load-use 延迟不变。
Forward gating（AMD K8 原生）：TLB 权限比较结果作为 forward enable 信号，权限不通过则 forward 网络不驱动。代价：TLB 权限 check 必须压缩到 1 cycle 内完成，对 TLB hit 延迟敏感的工作负载（如 pointer-chasing）有轻微影响。
瞬态窗口清空（ARM 某些 Cortex-A 核心）：检测到异常后立即 flush 整个 LSU + ROB，强行终止瞬态执行。代价：异常处理延迟增加 20–30 cycle，对异常敏感的虚拟机监控器（频繁触发 page fault）有显著影响。
三种路线都能修复 Meltdown，但对不同工作负载的代价分布不同。Intel 最终选择零值替代，AMD 和 ARM 各自选择与自家微架构契合的方式。
从 Meltdown 到 KPTI。P6 的设计原罪无法通过软件完全修复——内核只能隐藏映射让 Meltdown 无"可读数据"。这正是 KPTI（Kernel Page Table Isolation） 的核心思想：维护两套页表，用户态页表中不映射内核的其余部分。Meltdown 瞬态执行仍然会访问"内核虚拟地址"，但由于该地址在用户态页表中未映射，page walker 会返回 Present 0——等等，这不就又回到 L1TF 了吗？答案是：KPTI 必须与 PTE Inversion（反转未映射 PTE 的 PFN 字段为一个必然不在物理内存范围内的假地址，例如 max_pfn ）配合使用，否则 KPTI 本身会把用户暴露给 L1TF。这个精巧的软硬件协同防御，以及 KPTI 对系统调用密集型负载的 性能代价，将在下一章（第 51.0 章）详细展开——那里我们会看到 Linux 内核为了抵御 Meltdown 与 L1TF 同时付出的工程努力，以及 Intel Ice Lake 硬件修复之后 KPTI 如何从"必选"降级为"可选"。
设计提示
Meltdown 与 L1TF 共同揭示了一条深刻的原则：微架构优化必须对"异常数据流"与"正常数据流"同样谨慎。P6 认为异常是稀有事件，L1TF 则揭示"PTE Present 0"这种"本应不存在"的状态在微架构层面并不真的被抑制。2030 年代安全的 OoO 设计必须在 load 单元引入显式 interlock：任何可能影响微架构可见状态（Cache、TLB、分支预测器）的 forward/update，都必须等待完整的权限与有效性检查结果——哪怕付出 1–2 cycle 的延迟代价。这是 23 年原罪教给产业界的最贵的一课。
Retbleed与RSB下溢
Retbleed（2022年披露，CVE-2022-29900/29901）是一种利用返回指令（RET）的分支预测行为来实施跨特权级攻击的瞬态执行漏洞。Retbleed的重要性在于它揭示了ret指令——此前被认为是"安全的"间接分支形式（Retpoline正是基于这个假设）——实际上也可以被攻击者利用。
RSB下溢问题
处理器使用返回栈缓冲区（Return Stack Buffer, RSB）来预测**RET指令的目标地址。RSB是一个LIFO（后进先出）栈结构——CALL指令将返回地址压入RSB，RET**指令从RSB弹出地址作为预测目标。在大多数情况下，RSB的预测非常准确（99%），因为程序的call/return通常成对出现。
然而，当RSB下溢（underflow）时——即RSB中没有条目可供弹出——处理器需要使用后备预测器来预测**RET**的目标。在Intel处理器中，RSB下溢时的后备预测器是BTB（间接分支预测器）。
Retbleed的攻击正是针对这个后备预测器：当内核中的**RET指令触发RSB下溢时，处理器使用BTB来预测返回地址。攻击者可以像Spectre v2一样通过在用户态训练BTB，将内核的RET**重定向到攻击者选择的gadget地址。
攻击条件与防御
Retbleed攻击需要满足以下条件：（1）内核代码中存在**RET**指令在RSB下溢时被执行的情况；（2）攻击者能够训练BTB；（3）内核中存在可利用的gadget。
防御措施包括RSB填充（在特权级切换时向RSB填充安全地址）、改进RSB下溢处理（不使用BTB作为后备预测器）和IBPB（清除全部间接分支预测器状态）。
案例研究 5 — Inception攻击（2023年）
Inception（CVE-2023-20569）是Retbleed的一个变种，利用幻影推测（Phantom Speculation）——处理器在某些非分支指令位置也可能产生推测执行。Inception的危险在于它绕过了传统的Retpoline和IBRS防御。AMD通过微码更新修复了Inception漏洞。
MDS（微架构数据采样）
MDS（Microarchitectural Data Sampling）是2019年披露的一组漏洞，它们利用处理器内部微架构缓冲区（如填充缓冲区、加载端口、存储缓冲区）中残留的数据来泄露信息。与Spectre和Meltdown不同，MDS攻击读取的不是特定地址的数据，而是微架构缓冲区中恰好残留的数据——这些数据可能来自任何先前的操作，包括其他进程或内核的操作。
MDS包含三个主要变种：
（1）MFBDS（Microarchitectural Fill Buffer Data Sampling），也称为Fallout。填充缓冲区（Line Fill Buffer, LFB）是L1 Cache与L2 Cache/主存之间的中间缓冲区，用于暂存正在进行的Cache行填充操作。当一个L1 Cache缺失发生时，处理器分配一个LFB条目来跟踪这次缺失，并在数据从下级Cache/内存返回时暂存数据。LFB的条目数量有限（通常为10–12个），并且在不同操作之间不会被清零——新的缺失操作复用旧条目时，旧数据仍然残留。
MFBDS攻击的关键在于：当攻击者执行一条load指令，且该load在微架构上产生了某种错误条件（如访问未映射页面、推测执行中的load），处理器可能会从LFB中返回陈旧数据（stale data）而不是触发正常的缺失处理流程。这些陈旧数据可能是之前内核或其他进程的Cache行填充中残留在LFB中的数据。
（2）MLPDS（Microarchitectural Load Port Data Sampling），也称为RIDL（Rogue In-Flight Data Load）。加载端口（Load Port）是将数据从Cache/内存系统传送到执行单元的硬件通道。在某些Intel处理器中，当推测执行的load指令遇到错误条件时，加载端口可能会将其内部缓冲区中先前传输的数据转发给请求者，而不是返回错误或等待正确的数据。
（3）MSBDS（Microarchitectural Store Buffer Data Sampling），也称为ZombieLoad。存储缓冲区（Store Buffer）用于暂存已执行但尚未提交到Cache的store指令的数据。在正常的store-to-load转发中，如果一条load指令的地址与存储缓冲区中某条store的地址匹配，处理器直接从存储缓冲区中转发数据，避免了Cache访问。MSBDS漏洞在于：某些条件下，即使地址不完全匹配，处理器仍然可能从存储缓冲区中转发数据（部分地址匹配的错误转发），导致来自其他安全域的store数据被泄露。
MDS的威胁模型。MDS攻击的一个重要特征是攻击者无法选择要泄露的数据——它只能获取微架构缓冲区中恰好残留的数据。这意味着攻击者需要多次采样并进行统计分析，才能可靠地提取目标数据。然而，在SMT（超线程）环境中，攻击者和受害者共享同一物理核心的微架构缓冲区，攻击者可以在受害者正在执行时同步采样，大大提高了获取目标数据的概率。
防御措施。（1）微码更新——Intel发布了微码补丁，在安全域切换时（如用户态内核态、VM切换）自动清零微架构缓冲区（使用**VERW**指令触发）。（2）禁用SMT——由于MDS在SMT环境中威胁最大，某些安全敏感的工作负载选择禁用超线程。（3）硬件修复——从Ice Lake开始的处理器在硬件中修复了大部分MDS漏洞，方法是在微架构缓冲区条目被复用时自动清零旧数据，以及在store-to-load转发中加强地址匹配检查。
硬件描述 8 — 微架构缓冲区的安全清零设计
MDS漏洞揭示了一个处理器设计中长期被忽视的安全原则：微架构缓冲区在被复用时必须清零。在传统的处理器设计中，缓冲区条目的valid位足以确保功能正确性——一个被标记为无效的条目不会被正常操作使用。然而，MDS表明在异常执行路径中（如推测执行中的错误load），处理器可能绕过valid位检查，直接访问缓冲区中的陈旧数据。
安全的设计需要确保：（1）所有微架构缓冲区（LFB、存储缓冲区、加载端口缓冲区等）在条目被释放或复用时物理清零数据字段；（2）在安全域切换时（特权级转换、上下文切换、VM切换），对所有可能包含敏感数据的缓冲区执行批量清零。
清零操作的性能代价通常很小：对于LFB（12个条目64字节），批量清零需要约2–3个周期（使用宽数据通路）；对于存储缓冲区（56–72个条目8字节数据），清零需要约4–6个周期。这些操作可以与安全域切换的其他开销（如TLB刷新、BTB隔离）重叠，因此增加的额外延迟很小。
ZombieLoad（CVE-2018-12130）：LFB 残留数据采样
**LFB 的本职工作。**LFB（参见第 8.0 章的 MSHR/LFB 段落）是 L1D 与 L2 之间的 10 条目缓冲队列，每条目 64 字节数据加上地址、valid、dirty、state 等元数据。当一条 load 在 L1D miss 时，它被挂到一个 LFB 条目上，后续从 L2/LLC/DRAM 返回的数据先写入 LFB，再同时向请求的 load 端口 forward 并填入 L1D。LFB 还处理写合并（write-combining）、非时序写、以及 L1D 的 eviction fill。
泄露路径。ZombieLoad 的核心观察是：当一条 load 触发某种微码 assist 或 fault（例如 #PF、#GP、或 non-canonical 地址），Skylake 的实现会在瞬态窗口中从某个 LFB 条目转发陈旧数据给这条 fault load——即使该条目的 valid 位表明它对应的是完全不同的物理地址、甚至属于另一个 SMT 逻辑核心的 load。这些陈旧数据可能是几十个周期之前另一个线程的 L1 miss 填充、或是内核在上下文切换前的 LFB 残留。攻击者把收到的陈旧数据当作下一条"Flush+Reload gadget 地址"的索引，用 cache 侧信道完成信息泄露（参见50.3.3 节中介绍的同款瞬态泄露范式）。
触发条件。攻击 μop 需要满足两个条件：（1）该 load 在架构上必然 abort（如访问 kernel 页、non-canonical 地址，或读 SGX enclave 页）；（2）紧随其后的 μop 必须对该 load 的结果有数据依赖，以便把陈旧数据编码成 cache 足迹。由于 fault 要到 retire 时才 raise，瞬态窗口长达数十个周期，足够跑完完整的编码循环。
SMT 跨特权。最致命的变种是跨 SMT：受害者线程正常运行在同核另一个逻辑核上，它做的每一次 L1 miss 都会短暂地把数据驻留在 LFB；攻击者线程以高频率执行 fault load，就像用一张"采样网"在 LFB 上捞鱼，可以以 KB/s 量级稳定泄露隔壁线程的敏感数据。这让 ZombieLoad 成为云厂商的噩梦——Intel 建议对不信任的 tenant 一律关掉 SMT。
修复。Intel 把 VERW 的微码语义重载：原本 VERW 只用来校验段描述符是否可写，现在通过微码更新，VERW m16 的执行会隐式触发 MD_CLEAR 操作——清空 LFB、Load Port forwarding register、Store Buffer 中所有条目的数据字段。内核在每次 userkernel、kerneluser、vmentry/vmexit 的边界执行一次 VERW，代价约为 20–40 个周期。
RIDL（Rogue In-Flight Data Load）
泄露源：Load Port 的 256-bit forwarding register。Skylake 的 Load Port 0/1 内部各有一个 256-bit 宽的临时 forwarding register，用来缓冲从 L1D 或 LFB 返回的数据、在送到 PRF 之前进行对齐、符号扩展、子字节选择等预处理。RIDL 发现：当一条 load 进入某些微码 assist 路径（如 split-line load、faulting load、或特定的 AVX gather 微码分解）时，Load Port 可能把该寄存器中上一次成功 load 的残留数据转发给当前 μop，而不是从 L1D 真正取数。
与 ZombieLoad 的差别。RIDL 的独特之处在于：即便当前 load 在架构上成功完成（没有 fault），它仍然可能因为走了 assist 微码路径而拿到 forwarding register 的残留。这意味着攻击代码不需要故意制造 page fault，只需要构造能够触发 assist 的 load（例如跨 cacheline 的非对齐 load、或 gather 中 mask 部分设置的通道），隐蔽性比 ZombieLoad 高得多。
浏览器沙盒逃逸。RIDL 的低触发门槛使其成为第一个被证明可以从 WebAssembly/JavaScript 直接利用的 MDS 变种：攻击者在浏览器中通过精心构造的非对齐 load 串，就能以几百 bits/s 的速率泄露同进程其它 site 的数据。Chrome 的 site isolation（每个 origin 一个进程）是必要防线。
**修复。**与 ZombieLoad 共享同一个 VERW+MD_CLEAR 微码路径：MD_CLEAR 在清 LFB 的同时，也会清两个 Load Port 的 forwarding register。
Fallout / Store-to-Leak：Store Buffer 乐观 forwarding
泄露源：Store Buffer 的 address-independent forwarding。Store Buffer（参见第 37.0 章）保存 56 条已执行但尚未 commit 的 store，每条含{addr, data, size, valid, addr_ready}。正常的 store-to-load forwarding（STLF）要求 load 的地址与某条 store 的地址完全匹配（或满足 size/alignment 的子集匹配）才能 forward data。Skylake 的问题出在乐观 forward这条优化路径上：当一条 store 的地址尚未就绪（AGU 还没算完）而其 data 已经就绪时，若后续 load 的地址低位（如 page offset 的某几位）与该 store 的部分地址 hint 匹配，处理器可能推测性地把 store 的 data forward 给该 load，事后再校验完整地址。若校验失败，流水线 squash 这条 load——但它的 data 已经在瞬态窗口中被后续的 encoding gadget 观察到了。
威胁模型。Fallout 在 Meltdown 被硬件修复后的 Coffee Lake Refresh 上依然有效，因为 Meltdown 的修复只影响 L1D 到 PRF 的推测路径，不触及 Store Buffer 的 forwarding 逻辑。利用 Fallout 可以读取内核最近执行的 store：譬如内核刚刚写入某个存放 user-pointer 的栈变量、或者在 syscall 入口处 spill 了某些寄存器，这些 store 在 commit 前会在 Store Buffer 中存活数十到上百个周期，足以被攻击者采样。
**修复。**微码禁用"address-unresolved store 的乐观 forwarding"——只有在 store 地址完全就绪后才允许 forward。典型工作负载上带来约 3% 的 IPC 损失，因为 STLF 的命中率下降导致更多 load 需要等待 store 完全 retire。
TAA（TSX Asynchronous Abort, CVE-2019-11135）
TSX 作为瞬态窗口的"天然产生器"。Intel TSX 提供硬件事务内存：一个 XBEGIN...XEND 包起来的事务在遇到冲突、容量超限、fault 等情况时会异步 abort，回滚所有事务内的架构状态。TAA 的洞察是：TSX abort 的回滚是架构级别的，但事务内执行的 μop 对 LFB、Store Buffer、Load Port 的微架构副作用并未被回滚。
攻击流程。（1）攻击者在事务内放一条故意触发 assist 的 load（例如 non-canonical 地址的 load）；（2）紧接着是一段 Flush+Reload encoding gadget，把该 load 的结果编码为 cache 足迹；（3）TSX 检测到 fault，启动异步 abort——但 abort 的"瞬态尾巴"允许 gadget 的若干条 μop 继续执行完毕；（4）事务 rollback 后，攻击者在事务外 probe cache，读出残留的 LFB 数据。
相对其他 MDS 的优势。TAA 不需要分支预测器训练：TSX abort 路径本身就是一个天然的、可以反复触发的瞬态窗口，攻击者无需像 Spectre v1 那样小心训练 BHB，也不用像 ZombieLoad 那样依赖 page fault 的精确 timing。这使 TAA 的可复现性和数据率在 MDS 四件套中最高。更糟的是：在 TAA 披露时，很多部署了 ZombieLoad 微码的机器以为自己已经安全，但旧微码的 MD_CLEAR 不会在 TSX abort 的边界触发，于是 TAA 绕过了已有的 VERW 防线。
修复。Intel 发布了 TSX_CTRL MSR（0x122），提供 RTM_DISABLE 和 TSX_CPUID_CLEAR 两个位。操作系统默认设置 RTM_DISABLE=1，使所有 XBEGIN 立即进入 abort handler，事务内代码永不执行——相当于从源头切断瞬态窗口。TSX 在绝大多数工作负载上使用率极低（仅 glibc 的某些 lock elision 路径、以及少数数据库利用 RTM），禁用后 IPC 损失 0–3%；对重度依赖 HLE/RTM 的负载（如某些事务性 KV store）才有显著影响。新一代微码甚至永久熔断 RTM，使其在后续启动中无法被重新开启。
硬件描述 9 — LFB 条目的物理布局与清零代价
Skylake 的 LFB 条目是理解 ZombieLoad 与 TAA 的关键。每个条目大致包含以下字段：
64 字节 data buffer：真正的 cache line 数据，组织为 88B 的 bank 以支持对齐/不对齐的 byte enable。
Physical address tag：40–46 位物理地址（去掉 block offset）。
Request type：load-fill、store-miss、write-combining、non-temporal、prefetch、eviction-writeback 等。
Status 位：allocated、data_valid、sent_to_L2、fill_complete、stale。
Requester bitmap：哪些 load queue 条目在等这条 fill 的 data，用于 broadcast forward。
MESI 次态、poison 位、ECC。
关键危险点：LFB 条目被释放时，处理器仅仅清 allocated 位，不主动覆写 data buffer。下次被分配时，若新 load 尚未收到 L2 返回的数据，但它通过 assist 路径读取 data 字段，就拿到了上一次 fill 的残留。
MD_CLEAR 的硬件实现是加一条"微码序列"：遍历全部 10 个 LFB 条目，对每个 data buffer 写入全零；对 Load Port 的两个 256-bit forwarding register 并行清零；对 Store Buffer 的 56 条 data 字段清零。利用 L1D 写端口的 256-bit 宽度，全部清零在约 20 个周期内完成，再加上 VERW 自身解码和微码 dispatch 开销，整体约 30–45 周期，与一次 L2 hit 的延迟同量级。
案例研究 6 — MDS 微码发布时间线
MDS 四件套的修复是 Intel 安全响应史上规模最大的一次微码联动更新：
2018年6月：荷兰 VU 的 Kaveh Razavi 团队向 Intel 报告 RIDL 的最早迹象；奥地利 TU Graz 的 Daniel Gruss 团队独立报告 ZombieLoad。Intel 在严格 NDA 下开始研发 MD_CLEAR 微码与 VERW 语义重载方案。
2019年5月14日：Intel 同时公开 MDS 白皮书、发布覆盖 Nehalem 到 Coffee Lake 的微码更新（MCU 20190514），Linux 内核合并 mds=full 缓解选项，主要云厂商（AWS、Azure、GCP）宣布完成舰队级别的微码升级。同一天，各 Linux 发行版紧急发布内核更新。
2019年8月：Apple、Microsoft、Google 完成浏览器端对 RIDL 的缓解（进一步强化 site isolation、限制 SharedArrayBuffer 与高精度定时器）。
2019年11月12日：TAA 披露，Intel 发布 MCU 20191112，引入 TSX_CTRL MSR；Linux 5.4 合入 tsx=off 缺省策略。此时约有 20% 的既有 Skylake/Cascade Lake 服务器尚未升级到此微码，形成一个"旧微码但以为已经修好"的危险窗口。
2020年6月：SRBDS（Special Register Buffer Data Sampling）披露，作为 MDS 范式的变种，Intel 再次发布 MCU 补丁对 RDRAND/RDSEED 的 staging buffer 做清零。
2021-2022年：Ice Lake 及之后的硬件修复开始普及——LFB 在条目复用边界自动清零、Store Buffer 禁用 addr-unresolved forwarding、Load Port forwarding register 在 assist 路径上硬件清零。运行在 Ice Lake+ 的 Linux 内核可以在 mds=off 下安全运行，VERW 的 30–45 周期代价被彻底省下。
2023-2024年：Downfall（GDS）表明 AVX2 gather 的 staging buffer 仍是 MDS 范式的未清区域，再次证明"每一个未清零的微架构缓冲区都是潜在的 MDS 位点"。
性能分析 8 — MDS 系列 vs Meltdown：攻击面与代价对比
下表横向对比 Meltdown 与 MDS 四件套的关键特征，帮助读者建立"攻击源触发机制数据率修复代价"的统一心智模型。
| 攻击 | 泄露源 | 触发 | 数据率 | 修复 | IPC 损失 |
|---|---|---|---|---|---|
| Meltdown | L1D | #PF fault load | 500 KB/s | KPTI / 硬件 | 2–5% (KPTI) |
| ZombieLoad | LFB (1064B) | fault + 依赖 μop | 10–50 KB/s | VERW/MD_CLEAR | 1–3% |
| RIDL | Load Port 256b fwd | assist μop | 1–10 KB/s | VERW/MD_CLEAR | 与 ZL 同路径 |
| Fallout | Store Buffer 56 项 | 乐观 STLF | 1–5 KB/s | 禁用乐观 fwd | 3% |
| TAA | LFB via TSX abort | XBEGIN+fault load | 20–100 KB/s | TSX_CTRL=off | 0–3% |
三条可视的共性规律。（1）数据率随缓冲区深度与瞬态窗口可复现性线性增长——TAA 因为 TSX abort 是"自动化的瞬态窗口"而数据率最高；（2）一旦源头是共享的微架构缓冲区，SMT 跨线程攻击就不可避免，修复的性能代价也就必须摊到每一次特权级切换上；（3）MDS 的单位 IPC 损失虽然小，但要与 Meltdown/Spectre v2 的缓解叠加——典型生产服务器开满所有缓解后，总 IPC 损失可达 10–17%（参见本章后文关于总体性能代价的讨论）。
结论：MDS 真正教会架构师的是"每个未主动清零的微架构缓冲区都是一个等待被发现的侧信道"，这条原则在 Downfall、Zenbleed 等后续漏洞上被反复验证。Ice Lake 之后的硬件开始把 MD_CLEAR 语义内生于微架构：条目复用时硬件自动清数据，特权级切换时 LFB/Store Buffer/forwarding register 在零周期代价下被清零——这是处理器安全从"补丁"走向"架构"的关键一步。
Retbleed和Inception等新变种
瞬态执行攻击的研究仍在持续演进。2022年和2023年，研究者分别披露了Retbleed和Inception两个重要的新变种，它们揭示了return指令的预测机制也可以被利用来发起Spectre类攻击。
Return Stack Buffer（RSB）。处理器使用RSB（Return Stack Buffer，也称为RAS，Return Address Stack）来预测ret指令的返回地址。每当处理器执行一条call指令时，将返回地址压入RSB；执行ret时，从RSB中弹出一个地址作为预测的返回目标。RSB的容量通常为16–32个条目。
RSB下溢问题。当RSB中的条目被耗尽时（即连续执行的ret次数超过RSB的容量），处理器需要回退到其他预测机制。在Intel的某些处理器中，当RSB下溢时，处理器会使用BTB来预测ret的目标。而BTB的预测是可以被攻击者训练的（类似Spectre v2）——这就是Retbleed攻击的基础。
**Retbleed攻击（CVE-2022-29900/29901）。**2022年，Wikner和Razavi披露了Retbleed漏洞。攻击步骤如下：
（1）**RSB清空。**攻击者通过执行深层嵌套的函数调用和返回来耗尽RSB。
（2）**BTB训练。**利用RSB下溢后处理器回退到BTB预测的行为，攻击者训练BTB将内核代码中的ret指令的预测目标设置为gadget地址（类似Spectre v2的BTB中毒）。
（3）**触发内核返回。**通过系统调用使内核执行包含ret指令的代码路径。由于RSB下溢，处理器使用BTB预测的目标（被攻击者训练为gadget），推测性地执行gadget代码。
Retbleed的重要性在于它绕过了Retpoline防御。Retpoline正是通过将间接跳转替换为ret指令来防御Spectre v2的——它假设ret指令由RSB预测，而RSB不会被攻击者直接训练。然而，Retbleed表明当RSB下溢时，ret的预测退化为BTB预测，攻击者可以通过训练BTB来重新控制ret的推测执行目标。
Retbleed的防御。（1）RSB填充（RSB stuffing）：在从用户态返回内核态时，软件主动将RSB填满（push足够多的虚假返回地址），防止内核执行期间RSB下溢。Linux内核在Retbleed披露后实现了这种防御。（2）IBRS：在支持eIBRS的处理器上，即使RSB下溢导致BTB预测，eIBRS也能确保用户态的BTB训练不影响内核态的预测。（3）硬件修复：部分处理器通过微码更新增加了RSB下溢时的备用预测机制，避免回退到BTB。
**Inception攻击（CVE-2023-20569）。**2023年，Daniël Trujillo等人披露了Inception攻击，它引入了一个全新的概念：在瞬态执行中训练预测器（Training in Transient Execution, TTE）。
传统的Spectre类攻击需要在架构执行（正常的、已提交的执行）中训练预测器。这意味着攻击者需要实际执行分支指令来更新BTB/PHT的状态。然而，Inception发现在推测执行路径中执行的分支指令也会更新预测器状态——即使这些指令最终被撤销，它们对预测器的训练效果仍然保留。
Inception攻击利用这一发现，构造了一个嵌套的推测执行攻击：（1）外层推测执行用于训练预测器（在瞬态执行窗口中放置精心构造的分支指令来训练BTB）；（2）内层推测执行利用刚刚训练好的预测器来将受害者重定向到gadget。这种嵌套的瞬态执行使得攻击可以绕过某些假设"预测器训练需要架构执行"的防御措施。
Inception主要影响AMD的Zen 3和Zen 4处理器。AMD通过微码更新和IBPB（Indirect Branch Prediction Barrier）的增强来缓解这一漏洞。
案例研究 7 — 瞬态执行攻击的演进时间线
瞬态执行攻击从2018年被公开以来，新的变种不断涌现，形成了一个持续演进的攻防博弈：
2018年1月：Spectre v1/v2和Meltdown同时披露，影响几乎所有Intel、大部分AMD和部分ARM处理器。软件缓解措施（LFENCE、Retpoline、KPTI）被紧急部署。
2018年5月：Spectre v3a（Rogue System Register Read）和Spectre v4（Speculative Store Bypass）被披露。v4利用推测性的store-to-load转发来绕过内存依赖。
2019年5月：MDS（RIDL/Fallout/ZombieLoad）被披露，攻击矢量从Cache扩展到了微架构内部缓冲区。
2019年11月：TAA（TSX Asynchronous Abort）被披露，利用Intel TSX事务内存的异步中止来触发类MDS的数据泄露。
2021年：Intel对L1D Cache的安全性进行了增强，在VM切换时自动刷新L1D Cache。
2022年7月：Retbleed被披露，证明Retpoline防御可以被RSB下溢攻击绕过。
2023年8月：Inception被披露，引入了在瞬态执行中训练预测器的新攻击范式。
2023年9月：Downfall（GDS，Gather Data Sampling）被披露，利用Intel AVX2/AVX-512的**GATHER**指令中的微架构优化来泄露数据。
这一时间线清楚地表明：处理器安全不是一个一次性修复的问题，而是一个持续的攻防博弈。每一代处理器都需要在设计阶段就系统性地审计所有微架构优化的安全影响。
设计提示
瞬态执行攻击的根本原因在于处理器的一个基本设计假设：推测执行被撤销后不会产生可观测的影响。这个假设在架构层面是正确的（寄存器和内存状态被完美回退），但在微架构层面是错误的（Cache、TLB、分支预测器的状态变化不会被回退）。要从根本上解决瞬态执行攻击，有两条路径：（1）保守路径——限制推测执行期间可以执行的操作，例如禁止推测load越过安全边界、禁止推测执行的结果影响Cache状态等，代价是显著降低推测执行的性能收益；（2）激进路径——使微架构状态变化也可逆（transactional microarchitectural state），在推测执行被撤销时同时回退所有微架构副作用，代价是需要为所有微架构状态维护检查点和回退机制，增加硬件复杂度和面积。学术界和工业界目前倾向于在两条路径之间寻找折中方案：选择性地保护最敏感的微架构状态（如Cache），同时利用硬件和软件的协同防御来覆盖其他攻击面。
LVI（Load Value Injection）
在2018–2019年公开的瞬态执行攻击谱系中，Spectre/Meltdown/MDS 都遵循同一种"窃取"范式——攻击者诱导受害者的瞬态路径读出敏感数据，然后通过某个微架构副信道把秘密发出去。2020年Van Bulck等人在S&P 2020披露的LVI（Load Value Injection，CVE-2020-0551）则反向打破了这个假设：攻击者不再是"偷"，而是"注入"——把自己预置的值塞进受害者的瞬态计算，使后者沿着污染路径自己把秘密吐出来、或者在 SGX 内执行攻击者想要的控制流（参见 50.3.3 节 的威胁模型对照）。
**注入通道：LFB 与 L1D 的推测 forward。**LVI 的物理通道与 MDS（参见 50.3.5 节）完全同源：Line-Fill Buffer（LFB）、Store Buffer 与 Load Port 之间存在推测性的数据转发——当一条 load 因缺页、UC（uncacheable）内存类型、或 XBEGIN 后读失败而即将触发 fault 时，Intel Skylake/Kaby Lake 家族的 LFB 会先把 LFB 中最新的某个字段 forward 给这条注定失败的 load，然后才在 retirement 时把异常打给软件。MDS 的攻击者利用这段时间把 forward 值泄露出来；LVI 的攻击者则提前在自己能控制的 LFB 条目里放好"想要注入的值"，让被 fault 的 load 把这个污染值投递到受害者的瞬态依赖链上。
**SGX 内的灾难级场景。**LVI 之所以在披露当年引起工业界的最高等级响应，是因为它对 Intel SGX 威胁模型造成了根本性冲击。SGX 的安全假设之一是 enclave 内部的代码、数据、控制流都由硬件保护——哪怕 OS 内核被攻破，攻击者也无法修改 enclave 的内存。LVI 绕过了"修改"：它不需要改写 enclave 内存，只需要在 enclave 触发 page fault 或 XBEGIN abort 时，注入一个值到 enclave 的某条 load 的瞬态结果中。只要 enclave 里存在类似 if (ok) call_trusted else call_fallback 这样再普通不过的分支，攻击者就可以污染 ok 让 enclave 的控制流走到攻击者选择的一侧，进而在 enclave 内执行 ROP gadget。
案例研究 8 — LVI 在 SGX enclave 内构造任意函数调用
Van Bulck 等（2020）展示的 PoC 针对 Intel SGX SDK 提供的一个生产级加解密 enclave。原始代码大致如下：
// 受害者 enclave 内（SGX SDK 加密路由器）
void handle(request_t *req) {
key_t *k = lookup_key(req->id); // 返回 enclave 内部指针
if (k && k->flags & KEY_AUTH) { // 这里的 k 会被 LVI 污染
do_auth(k, req); // 攻击者希望到这里
} else {
fallback(req); // 正常路径
}
}攻击步骤：（1）攻击者从 enclave 外不停执行带有精心构造值（指向攻击者控制的 fake key_t）的 XBEGIN abort，把这些值推入共享 LFB；（2）受害者进入 enclave 调用 handle()，在 lookup_key() 内部触发 page walk 或 UC 读失败，引起一次被 fault 的 load；（3）该 load 从 LFB 拿到攻击者预置的 fake 指针，瞬态路径上 k 被污染；（4）瞬态路径读 k->flags，它"恰好"有 KEY_AUTH 置位；（5）do_auth(k, req) 被推测调用，其内部对 k->sign_fn 的间接调用落在攻击者选定的 enclave 内 gadget。整条链不需要改 enclave 里一个字节。
Intel 的响应是 SGX SDK 2.9.1 引入 自动 LFENCE 插入：编译器在每条 load 之后插入一个 LFENCE，等价于把 enclave 的执行串行化到 load 粒度。在微基准测试上这引入 2–19 的性能代价，对真实加密负载约 3。
**汇编级最小 PoC。**为让根因具象化，下面这段 x86-64 汇编展示了"触发一次将被 fault 的 load + 让其 forward 值影响后续 dependent load"的最小内核：
; RAX: 攻击者预置在 LFB 的 fake pointer
; RCX: 受害者合法 base
mov rdx, [rcx] ; 常规 load，可能触发 page fault (rcx 指向 UC page)
; 在 fault 处理前的瞬态窗口，RDX 被 LFB forward 的
; 攻击者值污染，值 = RAX
mov r8, [rdx + 0x20] ; 瞬态依赖 load：用被污染的 RDX 作地址
; 该 load 把 (RAX+0x20) 对应的 cache line 拉进 L1
; …
; 稍后异常投递，上述两条 load 被 squash；但 L1 fill 留下副作用**硬件防御的正确方向。**软件层全自动插入 LFENCE 的方案只是应急补丁。真正的硬件修复需要让 LFB/Store Buffer 在跨安全域（用户态 enclave、userkernel）切换时被隔离并清零——这与 MDS 的 MD_CLEAR 微码机制是同一套基础设施（参见 50.3.5 节），但 LVI 要求隔离更严格：不仅要在切入时清空，还要防止在 enclave 执行期间有任何来自 ring 0 或其它核的 LFB 条目 forward 进 enclave 的 load port。Ice Lake（第10代）及之后的 Intel 处理器通过给 LFB 增加 domain-tag 位解决了这个问题：LFB 的每个条目除了物理地址 tag 还带一个 2-bit 的 domain id（user/kernel/enclave/hypervisor），forward 逻辑在 bypass 前先比对 domain id——domain 不匹配的 forward 直接抑制，迫使该 load 走完整的 L1 tag 阵列查找路径。代价是每次域切换多出约 30 cycle 的串行化，以及 LFB 存储面积增加约 4%。
**统一视角。**把 MDS 与 LVI 并列观察，可以得到一个关于瞬态执行攻击的更抽象结论：任何跨域共享的微架构 buffer，只要同时支持（a）推测读 forward 和（b）推测写污染，就会形成双向泄露通道。LFB、Store Buffer、Load Port 都同时具备这两个属性；2018–2024年披露的多数瞬态攻击本质上只是这张"双向通道表"上不同单元格的排列组合。
**与 Meltdown 的严格对偶。**有一个值得强调的对称性：Meltdown（50.3.3 节）让攻击者读取内核数据，LVI 让攻击者写入受害者瞬态——两者使用的是同一条 LFB forward 通道，只不过方向相反。若处理器厂商在设计 Meltdown 的硬件修复时只关注"禁止从 LFB forward 到跨域 load"（即只堵 Meltdown 方向），LVI 的反向通道将保持敞开。Intel 在 2019 年 Coffee Lake Refresh 的硬件 KAISER 修复就是典型——它给 LFB 加了"forward 方向审查"但只审查读方向，LVI 披露后 Intel 不得不在 Ice Lake 再补一次补丁把"forward 写方向"也纳入审查。这个故事是工程实践上"修一半比不修更危险"的教科书案例——它让被修补的特性继续运行但给了用户虚假的安全感。
Inception 与 PhantomJMP
前一节介绍的 Retbleed 已经触到了一个深层问题：当 RSB 下溢时，RET 的预测退回到 BTB，而 BTB 是按 PC hash 索引的——索引逻辑完全不关心这个 PC 处的指令到底是不是分支。Phantom（MIT/VU Amsterdam, 2022）和 Inception（ETH Zurich, CVE-2023-20569，影响 AMD Zen 1–4）把这一观察推向了极限：攻击者可以在根本不存在分支指令的 PC 上训练 BTB 条目，随后在受害者执行完全不同但 PC hash 碰撞的分支时命中这个幽灵条目。整个攻击不需要在架构上执行哪怕一条真实分支指令——"PhantomJMP"的名字就源于此。关于间接分支预测器的硬件细节参见 第 17.0 章。
**BTB 的索引方程暴露了原罪。**现代 BTB（无论是 Intel 的 BPU 还是 AMD Zen 的 L1/L2 BTB）的查找逻辑可以近似写为：
idx = hash(PC[47:12]) ; tag = PC[11:0] BHR
注意：索引的是 PC 的哪些位，而不是"这个 PC 是否曾经退休过一条分支指令"。在设计者的本意里，这个假设是合理的——编译器不会把分支放在非指令位置；但在攻击者视角下，这意味着只要能让某个 PC 在瞬态窗口内被 IFU 取到，并且该 PC 在预测阶段被当作分支处理，BTB 条目就会被更新。Phantom 的巧妙之处在于利用处理器的预解码与 BPU 查询并行的事实：BPU 在取指阶段就开始查 BTB，此时根本还不知道这个地址的字节会被解码成什么指令；如果 BPU 返回命中并给出一个预测目标，前端就按这个目标取指。架构上"这不是分支"的事实要等到解码级才被发现，而到那时条目已经被写入。
**Inception 的关键创新：训练发生在瞬态里。**传统 Spectre v2（参见 50.3.2 节）要求攻击者架构执行一条分支来训练 BTB——这意味着攻击者进程必须有权运行在和受害者 BTB 共享的核心上，并且要花时间做 mistraining 循环。Inception 把训练动作挪进了攻击者自己的瞬态窗口：攻击者先触发一个必然会被回滚的推测（例如一次故意误预测的 CALL），在这段瞬态内执行一条跳向PC_x的指令。即使该跳转最终被 squash，BPU 在尝试预测它时已经更新了 BTB 表项。整个"训练"发生在架构外，OS/KVM 根本看不见。
**为什么 IBPB 挡不住。**Intel 的 IBPB（Indirect Branch Prediction Barrier）在域切换时广播一个信号，要求 BPU 清空或使能隔离标签。但 IBPB 的实现细节是：它只会清掉过去架构执行过分支指令所训练的条目——因为微码设计者假定只有这些条目才"重要"。Phantom 条目来自一条在 PC_x 处从未被解码为分支的地址，BPU 的内部计数器不认为它属于"用户态训练过的分支"集合，于是 IBPB 跳过它。这是 AMD 在 Zen 4 微码里加强 IBPB 的"全量 flush"模式的原因——新模式不管三七二十一把整个 BTB SRAM 清零，但这会让 ring transition 延迟从原来的 400 cycle 涨到 2000 cycle。
硬件描述 10 — BTB 索引按 PC hash 的本质漏洞
BTB 之所以按 PC hash 索引而非按"最近退休过的分支 PC"索引，是容量与速度的双重约束所迫：
容量：现代 BTB 有 6 K–16 K 条目，如果要维护"该条目是否对应一条曾经退休过的分支指令"的元数据，就需要每条目至少多 1 bit 的 valid-bit 并在 retire 阶段更新——这条 retireBTB 的反向写回通路会占用写端口并干扰取指时的读端口。
速度：BTB 必须在 fetch 阶段的第 1 个 cycle 给出结果（否则会阻塞前端宽度 4–8 的取指带宽）。这要求索引逻辑只能是 PC 的若干 bit 做 XOR/CRC——没有时间查询该 PC 的"合法性元数据"。
结果：BTB 本质上是一张内容可被任意 PC 训练的缓存。它的安全性原本寄生在另一个隐含假设上——"只有真正取到并执行过的 PC 才会触发 BTB 更新"——而 Phantom 证明这个假设在深度推测流水线下不成立。
硬件修复方向：（1）给 BTB 增加 opcode-tag，在 decode 阶段确认该 PC 的字节确实是分支指令后才把条目标记为可用（AMD Zen 5 路线）；（2）在 BTB 入口额外用 BHR 而非仅 PC 做哈希（Intel eIBRS 增强版）；（3）在 ring transition 时无条件全量 flush BTB（最保守，性能代价最大）。
**Inception/PhantomJMP 与其他分支类攻击的分野。**如果把 Spectre v2 视作"被污染的 BTB 被架构执行的分支所 query"，那么 Retbleed 是"被污染的 BTB 被 RET（在 RSB 下溢后）query"，而 Inception 是"在瞬态内污染 BTB，被 RET（在 RSB 下溢后）query"。三者的防御交集是 50.3.6 节 提及的 RSB filling + IBPB 增强；但 Inception 特有的"瞬态训练"维度，要求在 ch51 §7.2 讨论 BHB Clear 机制时单独处理（前向桥接：见 第 51.0 章 的 BHB 相关章节）。
**AMD 微码层修复的成本。**Inception 披露后 AMD 在 2023 年 8 月发布的 ComboAGESA 微码把 IBPB 的行为从"按条目 invalidate"改为"整个 BTB SRAM 全量清零"。这改变了 IBPB 的微架构开销：原来在 Zen 3 上 400 cycle，新模式下 1900 cycle——主要因为 6 K 条目的 BTB SRAM 需要通过若干条内部 micro-op 清零（每 cycle 能清 8 条目）。在典型云场景下，ring transition 每秒发生 10 k–50 k 次，这意味着 Inception 微码缓解在 kernel-heavy 工作负载上带来 3%–10% 的稳态性能损失。AMD 在 Zen 4 Refresh 上给 BTB SRAM 增加了快速清零（wordline-level reset，1 cycle 清完）把该开销降回到 450 cycle——这是硬件层把微码层粗粒度修复精细化的典型案例。
**Phantom 对流水线前端设计的启示。**Phantom/Inception 最深层的启示是：现代高性能前端的"预测先于解码"设计在深度推测下不再是无条件安全的。一条未来指令是不是分支、跳转目标是什么——这些问题在经典教科书里是解码阶段的事，但在 5 GHz 以上的流水线上为了避免 fetch bubble，必须被推到取指的第 1 拍完成。BPU 被迫在"不知道这是不是分支"的前提下做预测，这是一个纯性能驱动的工程决策。Phantom 证明这个决策的安全代价是"任意 PC 都可以被训练"。下一代前端设计（如 Intel Glenmont 的 decoupled front-end 3.0）开始试验早期 pre-decode + BPU late query 的混合方案：pre-decoder 先用几 cycle 辨认"这个字节真的是分支指令"，再让 BPU query，代价是增加 2–3 cycle fetch-to-decode 延迟，但换来 BTB 训练被限制在真实分支 PC 上。这条路是否经济，取决于 BPU 面积与延迟预算，是 2030 年代前端架构的核心设计张力之一。
Downfall / GDS（Gather Data Sampling）
如果说 LVI 与 Inception 还算"数据通路设计"层面的事故，那么 Moghimi 在 USENIX Security 2023 披露的 Downfall（又称 GDS，Gather Data Sampling，CVE-2022-40982）则来自 SIMD 执行单元内部的一条隐蔽捷径。受影响范围覆盖 Intel 第 6 代（Skylake）到第 11 代（Rocket/Tiger/Ice Lake）共约 6 年的主力桌面/服务器处理器，几乎所有这一代 Intel CPU 上的 AES-NI、ChaCha20、Kyber/Dilithium（后量子）实现都受到直接威胁。
根因：AVX2/AVX-512 GATHER 指令的内部临时寄存器共享。VPGATHERDD/VPGATHERQQ 等 gather 指令在微架构上被分解为多个 μop（Skylake 上典型值是 5–8 μop）：1 μop 负责索引向量的分派，N μop 负责各个通道的独立 load，最后 1 μop 负责把结果拼合为一个 256-bit 或 512-bit 向量。关键在于中间这 N 个独立 load 共享一个临时聚合寄存器（internal temporary register，在 Intel 的微码中编号大致对应一个 ymm-wide 的物理寄存器池条目），gather μop 在每个通道 load 完成后把对应 lane 写进该临时寄存器，最后一步把它 copy 到架构可见的目的 ymm/zmm。
**SMT 共享让临时寄存器跨线程泄漏。**在 Hyper-Threading 启用的核心上，两个 SMT 线程共享同一套物理寄存器池与内部临时寄存器池。当线程 A 的 gather 完成时，它留下的临时寄存器值不会被立即清零（因为 μop 逻辑认为这是一个瞬态中间量，不值得花 cycle 去 zeroize）；当线程 B 紧跟着发起自己的 gather 时，gather μop 在某些失败路径（例如索引越界、触发 page fault、或 SMT 资源被抢占）下会从残留的临时寄存器中 forward 出值，污染 B 的 gather 瞬态结果。攻击者就是线程 B，它通过观察 gather 结果的值推断出线程 A 在它之前处理过什么敏感数据。
**为什么 GATHER 在密码学里无处不在。**Gather 是现代加密库的性能命脉：OpenSSL 的 AES-NI 软件路径在没有 AES-NI 指令的备份情况下用 gather 做 T-table lookup；libsodium 的 XChaCha20 用 gather 做 S-box；WebAssembly SIMD（V128）编译到 x86 的 shuffle 大量借助 gather；后量子密码库（如 PQClean 的 Kyber-768）用 gather 做 NTT（数论变换）。所有这些场景里敏感值都会经过 ymm/zmm 寄存器，而 ymm/zmm 的 gather-based 初始化会经过共享临时寄存器——直接被 Downfall 覆盖。
设计权衡 3 — Downfall 的微码修复——性能 vs 安全
Intel 于 2023 年 8 月发布了 0x0x4d/0x0x42 等微码更新，核心改动是把 VPGATHERDD/VPGATHERQQ 的 μop 调度从并行改为完全串行，并在每次 gather 后显式 VZEROUPPER 临时寄存器。效果：
正向：消除跨通道共享，消除 SMT 跨线程泄漏；MD_CLEAR/L1D-Flush 不再需要额外覆盖 gather 路径。
代价：AVX2-heavy 工作负载的 IPC 下降 5%–50%。具体：Intel MKL 的 DGEMM 在 Ice Lake 上测得 ；OpenSSL AES-GCM （它主要走 AES-NI，不依赖 gather）；但是 libquantum 的 QCBM 模拟 、某些图像处理 (gather-intensive bilinear) 下降 50% 以上。
部分退路：Intel 给管理员提供了一个 MSR（
IA32_MCU_OPT_CTRL.GDS_MITG_DIS）允许按虚拟机粒度关闭缓解——在不跑不可信代码的内部 HPC 负载上，管理员可以选择性回退以挽回 AVX 性能。这是"安全开关可配置化"的经典权衡案例。
更彻底的硬件修复见于 Raptor Lake（第 13 代）之后：gather 执行单元内部加入一条隐式 zeroize μop，把每个 lane 的临时寄存器在 gather 收尾时清零，代价只有 1–2 cycle 额外延迟，不再需要串行化整条 gather。这是硬件修复相对微码修复的典型性能优势——知道根因在哪的设计者可以精准打击那一条通路，而微码只能用"关大水闸"的粗粒度方案。
**最小 PoC：跨 SMT 的 gather 残留提取。**下面一段 C + intrinsics 展示了攻击者侧（SMT sibling B）如何通过一个注定 page fault 的 gather 从受害者 A 残留在共享临时寄存器的 value 中提取字节：
#include <immintrin.h>
#include <signal.h>
#include <setjmp.h>
static sigjmp_buf env;
static void sigsegv(int s) { siglongjmp(env, 1); }
// probe_base[256 * PAGE] : 每个候选字节对应一条独立 cache line
int downfall_probe(uint8_t *probe_base, size_t page)
{
// 构造索引向量：全部指向一个不可读页（必然触发 #PF）
__m256i idx = _mm256_set_epi32(0,0,0,0,0,0,0,0);
uint8_t *bad = (uint8_t *)0x0; // NULL → fault
signal(SIGSEGV, sigsegv);
if (sigsetjmp(env, 1) == 0) {
// 瞬态窗口：gather 在 retire 前把 SMT sibling 残留
// 到共享 staging reg 的值 forward 到 v 的某个 lane
__m256i v = _mm256_i32gather_epi32((int *)bad, idx, 1);
// 把 v 的 byte[0] 编码到 probe_base
uint8_t leak = _mm256_extract_epi32(v, 0) & 0xff;
(void)*(volatile uint8_t *)(probe_base + leak * 4096);
}
// 随后在 probe_base[0..256)*4096 上做 Flush+Reload，
// 哪条 cache line 命中，leak 就是哪个字节
return 0;
}**工程教训：SMT 共享资源的审计盲区。**Downfall 的影响之所以惊人（6 代 CPU、6 年窗口），是因为 gather 的共享临时寄存器既不在 Intel 的 architectural SDM 里，也不在 RDT/PQoS 等 QoS 模型的监控范围内——它是一个纯微架构的共享点，只在微码层可见。这提示我们：侧信道审计必须覆盖所有 SMT 共享结构，包括（但不限于）Cache/TLB/LFB/Store Buffer/Load Port/Branch Predictor/Execution Ports/Internal Temp Registers/Retirement FIFO——每一个都可能是下一个 Downfall。Intel 在 2023–2024 年启动的 STORM（Side-channel Threat Observation & Review Method）流程明确要求后续所有新 SIMD 扩展（如 AMX、APX）在设计阶段就必须提交 SMT 共享资源清单。
iLeakage（Apple Safari）
从 2018 年 Spectre 披露后，主流浏览器的防御核心思路之一是"降低 JS 计时器精度"——Chrome、Firefox、Safari 都把 performance.now() 的分辨率从 1 μs 钝化到 100 μs 甚至 1 ms，并禁用 SharedArrayBuffer。这让 Kocher 原版 Spectre v1 的 Flush+Reload 测时几乎失效（Cache hit 40 ns vs miss 200 ns 的差异被 1 ms 粒度彻底抹平）。2023 年 Wiebe 等人披露的 iLeakage（Apple M1/M2 + Safari WebKit）把 Spectre v1 的 oracle 从"时间"换成了"并行事件竞争"，绕过了这整条防御线。
**把 race condition 当时钟用。**iLeakage 的核心观察是：哪怕浏览器没给你高精度时钟，它也必然允许两个 Web Worker 真正并行运行（否则 JS 的多线程语义失效）。攻击者在一个 worker 里构造一个"快路径"（访问 L1 命中的 cache line），在另一个 worker 里构造"慢路径"（访问被 evict 过的 cache line），然后两者同时启动，最后通过 postMessage() 的到达顺序判断哪个先完成——顺序本身就是一个 1-bit 的时间比较。重复这个过程，就可以把 Flush+Reload 的"hit vs miss"重塑为"worker A 先 vs worker B 先"，不再需要时间戳。
// worker_fast.js
self.onmessage = async (e) => {
await e.data.startBarrier; // 和 slow worker 同时起跑
const x = probe[e.data.guess]; // 被瞬态执行填入 cache 的 guess line
self.postMessage({who: 'fast', val: x});
};
// worker_slow.js
self.onmessage = async (e) => {
await e.data.startBarrier;
for (let i=0; i<EVICT_N; i++) { evict_set[i] |= 0; } // 冷启动一次 eviction
self.postMessage({who: 'slow'});
};
// main thread (orchestrator)
const msgs = [];
worker_fast.onmessage = worker_slow.onmessage = m => msgs.push(m.data.who);
await Promise.all([worker_fast.ready, worker_slow.ready]);
startBarrier.signal(); // 让两边同时跑
await sleep(50); // 给两边足够时间
// 如果 msgs[0] === 'fast'，说明 guess 命中 cache，即 secret 的 bit == guess瞬态阶段仍然是标准 Spectre v1。真正泄漏 secret 的那一步没变：攻击者通过 JS 的 TypedArray 越界 + ArrayBuffer 共享等老套路，诱使受害者（例如跨 origin 的 Gmail 页面在同一进程内）进行越界 load，并把 secret_byte 编码到 probe 数组的一条 cache line 上（参见 50.3.1 节）。iLeakage 的创新只在探测阶段——用 race 替代 timer。
案例研究 9 — iLeakage 攻破 Gmail 收件箱的 PoC 结构
Wiebe 等在 2023 年公开的 PoC 展示了在 iPhone 14（Apple A16/M2 架构）的 Safari 17.0 之前版本上，攻击者网页可以静默读取已登录 Gmail 标签页的收件箱预览。链条如下：
进程内共存：Safari 在 iLeakage 发布时仍然不强制 site isolation——跨 origin 的 iframe 与攻击者页面可以共享同一个 Content Process（与 Chrome 早已默认 site-per-process 对比鲜明）。
Spectre v1 gadget：WebKit 的 JIT 编译器会把
arr[idx]的越界检查和后续 load 之间保留若干 cycle 的乱序空间，iLeakage 通过 mistraining PHT 让这条检查被预测 taken。Race oracle：用上面 listing 展示的双 worker 方案判断
probe[guess]是否命中。速率：大约 30–60 s/字节，一个收件人姓名（10–20 字节）在 5–15 分钟内恢复。
Apple 的响应分三条腿走路：（a）WebKit 17 强制 Site Isolation，让 Gmail 和 attacker.com 必须落在不同 Content Process；（b）在 JavaScriptCore 的 JIT 中引入 Speculative Load Hardening（SLH），把越界检查的 flag 与后续 load 的地址做 AND 运算，迫使瞬态路径上的 load 也指向合法范围；（c）在 M3/A17 起的新硬件上允许用户开启 DIT bit（见 50.3.11 节 与 ch51 §7.1），禁用数据依赖的微架构优化。
**Apple M1 的"慢路径"定义 race 精度。**iLeakage 作为 oracle 的成败取决于 race 粒度足够细。在 Apple M1 上实测发现：两个 WebWorker 之间 postMessage() 往返的最快时间约 1.5 μs（macOS 14.0 之前），这看起来远大于 cache hit/miss 的 ns 级差异。但 iLeakage 巧妙地用两个 worker 同时启动同一个循环任务、先完成者发信号的设计，把"单次 hit 与 miss 差 160 ns"放大为"循环 N 次后一方比另一方快约 ns"——只要 超过 postMessage 抖动，就能可靠判定。实验上 足够，对应 差异，显著大于 1.5 μs 的 postMessage jitter。
**缓存 eviction set 在浏览器内的构建。**iLeakage 另一个难点是在 JS 里构造可靠的 L1/L2 eviction set——这通常需要知道物理地址，但 JS 没有这个接口。攻击者利用 Safari 的 WebAssembly.Memory.grow() 返回的 ArrayBuffer 起始地址与 16 MiB 页对齐这一实现细节，通过反复分配和探测构造出 L2 eviction set，时间开销约 30 秒（一次性成本，之后整个会话复用）。该技术本身值得单独章节讨论，这里仅指出：浏览器 sandbox 并不天然隔绝 eviction set 构造，它只是拉高门槛。
**更深的教训：任何共享资源都是时钟。**iLeakage 的方法论值得单独强调——它证明降低时钟精度这一类应急防御在根本上是错的。任何一个可以让"事件 X 在事件 Y 之前完成"被双方观测到的共享资源，都可以当成时钟：Cache 占用率、LFB slot、execution port 占用、DRAM bank 冲突、甚至 CPU 温度传感器读数。哪怕浏览器把 performance.now() 的精度钝化到 1 秒，只要还允许并发执行，时钟就存在。这进一步印证了 50.3 节 的核心判断：瞬态执行攻击的根因在于微架构状态不随推测回滚——不修复这个根因，在 JS 层打时间精度补丁终究是一层窗户纸。
**Site Isolation 为什么是真正的修复。**iLeakage 披露后 WebKit 的"强制 site isolation"常被误解为"又一道补丁"，但它实际上是侧信道防御从"降低时钟精度"到"消除共享攻击面"的根本方向转变。Site Isolation 的核心保证是：不同 origin 的文档运行在不同 OS 进程中，而不同进程的 Cache 状态虽然仍共享硬件，但受 OS 调度与进程切换干扰极大，攻击者很难可靠地让自己的 probe 与受害者的 gadget 在同一 SMT 时隙内运行。这不是理论上消除泄漏（仍然有跨进程 Prime+Probe 的可能），而是把门槛从"几分钟攻破"拉到"几小时甚至几天都难以稳定利用"——足以让 Gmail 级别的敏感应用不再成为现实威胁。Chrome 早在 2018 年就推行 site-per-process；Apple 跟上得比较晚正是因为 Safari 的进程模型设计上更节俭（iOS 限制内存预算）。这揭示了硬件侧信道防御中一个被低估的工程原则：软件层面的 strong isolation 常常比任何硬件补丁都更有效，因为它从根本上减少了共享攻击面，而不是试图在共享面上做 fine-grained 访问控制。
GoFetch（Apple DMP）
2024 年 Chen 等人披露的 GoFetch（Apple M1/M2/M3）把侧信道攻击面从"分支预测器/执行单元/Cache"扩展到了一个多数人此前忽略的位置：数据预取器。Apple 系硅自 M1 起内置一种激进的前沿预取器——DMP（Data Memory-dependent Prefetcher，见 第 7.0 章 的预取器谱系），它的工作方式彻底打破了"预取器只用地址不用数据"的传统设计边界。
**DMP 做了什么。**传统预取器（stride、stream、Markov 等）都根据访问地址序列预测下一个地址；它们绝不读数据内容。Apple DMP 反其道而行：当一条 cache line 被 fill 进 L1 时，DMP 扫描这条 line 里的 8 字节对齐位置，寻找"看起来像合法虚拟地址的值"——Apple 的启发式判定包括：低 48 位位于当前进程已映射的 VA 区间、高 16 位为规范 sign-extend（0x0000...... 或 0xFFFF......）、4 KB 对齐命中某个 recently-accessed page。任何满足上述启发的 8 字节值都被 DMP 当作"潜在指针"，DMP 主动向该地址发起一次 prefetch。
从纯性能角度，DMP 是一个大胜——链表遍历、对象图扫描、GC 的 mark-sweep 阶段都高度 pointer-chasing，DMP 可以把后续几跳的延迟隐藏；Apple 报道 5%–10% IPC 收益。从安全角度，它打开了潘多拉盒：只要攻击者能让某个密码学中间值的低 48 位恰好像一个合法指针，DMP 就会替他发起一次 prefetch，这条 prefetch 的 Cache 副作用可被 Prime+Probe 观察到，从而反推出原值。
GoFetch 团队通过黑盒实验重构了 DMP 的判定流水线（Apple 未公开规范）：
对齐扫描：每次 L1 fill 完成后，DMP 遍历 cache line 中 8 个 8-byte-aligned 位置（64B line / 8B slot = 8 slot）。
canonicality 检查：候选值的 bit[63:48] 必须全 0 或全 1（ARMv8 canonical VA 的 sign-extend 约束）。
VA 范围检查：候选值的 bit[47:12] 查询一个小型 VA-region filter（类似 TLB tag 的筛子，size 16 条），判定该 page 是否"最近被访问过"。
cooldown：DMP 对已 prefetch 的地址设置冷却期（ 几百 cycle），避免热点 retry。
issue：满足条件的候选触发 L1 prefetch，fill 到 L1 dirty/clean 位。
关键暴露点在第 3 步：VA-region filter 对同进程的页面都是"已访问"，所以攻击者只要保证"假指针"落在自己 map 过的任意页面（16 GiB user space 范围内几乎无门槛），就能触发 prefetch。Chen 等人进一步发现 DMP 触发是与架构执行路径解耦的——即使这条 load 本来就命中 L1（不产生 miss），DMP 仍然会独立评估数据内容并发预取。这意味着 GoFetch 不需要任何 Spectre 风格的瞬态窗口，它是一个架构可见行为的侧信道。
:::
**对后量子密码学的精准打击。**GoFetch 的杀伤力最大的目标是 constant-time 密码库——这些库的设计假设是"所有访问地址都与 secret 无关"，用条件 move 替代条件分支、用掩码替代查表——他们自信已经堵死了 Cache 侧信道。但 DMP 把 secret 的值本身当作泄露源：只要某个中间值（例如 Kyber 的 NTT 多项式系数、ECDSA 的 blinding 量）在某个中间步骤看起来像合法指针，DMP 就替攻击者把它暴露到 Cache 里。Chen 等人完整恢复了 Kyber-512 的私钥、Dilithium 的签名密钥、Go 语言标准库的 RSA 私钥，在 M1 上 54 分钟/密钥。
案例研究 10 — GoFetch 对 Kyber-512 的完整密钥恢复
Kyber-512（NIST PQC 第一批标准之一，CRYSTALS-Kyber）在解封装阶段需要计算 ，其中 是私钥多项式、 是密文的 NTT 表示。中间计算结果 的每一个系数都是 13-bit 值，但在 CPU 寄存器中以 64-bit 存储。攻击：
攻击者构造密文 ，使得在某个特定索引 上， 的 64-bit 表示的高 16 bit 为 0、低 48 bit 落在已映射 VA 范围，仅当 的特定 bit 等于 1 时成立。这需要解一个关于 的简单线性方程组（已知 Kyber 的模数与 NTT 结构）。
攻击者向受害进程发送该密文，触发 Kyber.Decaps。
受害者在乘法 reduction 阶段把 临时写入寄存器并溢出到 stack，该值被填入 L1。DMP 发现它像指针，发出 prefetch。
攻击者用 Prime+Probe 观察对应 L1 set 的占用变化——如果观察到 prefetch 痕迹， 的该 bit 为 1；否则为 0。
重复 次，恢复整个私钥 。
完整攻击 54 分钟恢复 Kyber-512 私钥（M1, 3.2 GHz, macOS 13）。攻击对 Dilithium、Go 的 crypto/rsa 同样有效。
**修复：不是微码能解决的。**DMP 嵌在 L1 fill 路径的固定硬件逻辑里，没有微码路径可以绕过它。M1/M2 上唯一的缓解方案是密码库自己避免让 secret-dependent 中间量经过 Cache——具体做法是对所有中间量做 mask + blind，使其 64-bit 表示永远无法通过 canonicality 检查（例如强制 bit[63] 为随机值）。这给加密实现增加了 20%–30% 的开销。真正的硬件修复要等到 M3：Apple 在 M3 中引入了 DIT（Data Independent Timing）位——当进程设置 DIT=1 时，DMP 被硬件级禁用，前向桥接参见 第 51.0 章 的 §7.1 DIT bit 机制讨论。代价是 5%–10% 的 IPC 损失（DMP 关了之后预取收益完全消失）。
**设计哲学的反思。**GoFetch 提出了一个对硬件设计者更根本的问题：预取器该不该读数据内容？DMP 的设计决策把"预取覆盖率"推到了一个新高度，但这条决策的安全代价在提案阶段无人审计——因为传统侧信道威胁模型只覆盖地址泄漏，不覆盖"数据内容间接影响微架构行为"。这是 2020 年代硬件安全审计必须扩展的新维度：任何以数据内容为输入的微架构优化，都必须纳入侧信道威胁模型。
**DMP 不是唯一的"数据内容驱动"结构。**GoFetch 之后研究者开始系统性地审计所有"数据依赖"的微架构机制：Intel 的 NPU Thread Director 在某些 Alder Lake 变体上根据访存模式的值熵做线程调度；AMD Zen 4 的 Branch Target Buffer 在某种 SKU 上对"看起来像回指地址的值"做二次索引；ARM 的 v9 MPAM 框架允许按数据 tag 区分 Cache 分区。这些机制无一例外都落入 GoFetch 式攻击面。VUSec 在 2024–2025 年有多篇 follow-up 工作暗示同类攻击在 x86 架构上同样存在，只是 Intel/AMD 的 DMP-like 结构实现更保守（不使用如此激进的启发式），可利用性暂时低于 Apple M-series。读者在研究 ch07 的预取器设计时应当带着 GoFetch 的教训——性能最大化的预取器与侧信道最小化的预取器天然处于张力之中，而这条张力线正是 2030 年代前沿预取器设计的核心设计空间。
SLAM（LAM-assisted transient execution）
2023 年 VUSec 披露的 SLAM（Spectre based on Linear Address Masking）是一个结构上很简短、但寓意极深的攻击：它不是发现了新的推测通道，也不是利用了某种未公开的硬件缺陷——它利用了Intel 为未来安全性专门设计的一个新特性，把它翻译成 Spectre 的放大器。这就是著名的"安全特性的副作用"案例。
**LAM 背景：为 ARMv8.5 TBI 对标的新特性。**Intel 的 LAM（Linear Address Masking）随 Sapphire Rapids/Meteor Lake 引入，允许内核用虚拟地址的高位若干 bit 存储元数据 tag（如 MTE 式的内存类型标签、GC 的对象类型、HWASan 的染色标签）。LAM-U48 模式下，用户虚拟地址的 bit[62:48] 被硬件忽略（不参与 TLB 比对、不做 canonicality 检查）；LAM-U57 则对应 5 级页表。设计初衷完全良性：给内核和运行时一个零成本的 tag 字段，不再需要软件先 mask 才能解引用。
**副作用：canonicality 检查的边界被硬件主动放宽。**Intel x86 的 canonical VA 约束原本要求 bit[63:48] 全 0 或全 1——这不仅是 VA 翻译的合法性条件，也是推测路径上的一个天然边界：任何非 canonical 指针的 load 都会立即触发 #GP（General Protection fault），该 fault 会较快中断瞬态窗口。LAM 启用后，bit[62:48] 被硬件忽略，意味着原本触发 #GP 的那一大类地址不再触发——它们现在被视作合法 VA。于是推测路径可以在这些"曾经非法、如今合法"的地址上持续更长时间，攻击者可用的 Spectre gadget 地址空间从 字节扩大到 字节，足足放大了 倍。
**攻击链：用 LAM 指针穿透原本被 canonicality 挡住的内核区间。**传统 Spectre v1（参见 50.3.1 节）在攻击内核时，gadget 的越界索引 必须让 array1 + x 落在一个合法 VA——这排除了 kernel low-half + user high-half 之间的 canonical gap。LAM 放宽后，攻击者可以构造带高位 tag 的指针，让 array1 + x 形式上"合法"（通过 LAM 检查）、语义上却落在原本被 canonical gap 挡住的 kernel 虚拟地址区间；瞬态路径上的 load 不会因 canonicality 被快速截断，有更多时间把数据编码到 Cache。实测上，SLAM 在 Sapphire Rapids 上把 Spectre v1 的字节泄露速率从 10 KB/s 提升到 30 KB/s，且可达地址空间显著扩大。
**微架构细节：为什么 canonical gap 原本能截断瞬态。**要理解 LAM 的"放大"效果，必须回到 canonicality check 在流水线中的位置。x86 的 AGU（Address Generation Unit，参见 第 27.0 章）在算出 effective address 后，会在执行阶段（不是 retire 阶段）立即做 canonical 检查——这比 TLB 访问还早一拍。如果检查失败，load 直接被标记为 fault，发射队列把后续依赖它的 μop 挡住，MSHR 不会被分配给这条 load，L1 也不会 fill。于是 canonical gap 在实际上充当了一个零延迟的瞬态"早期终结"机制——它让落在非规范地址的瞬态 load 在几个 cycle 内就被截断，Cache 副作用根本来不及产生。LAM 通过把 bit[62:48] 从 canonicality 检查中硬件级移除，直接把这个早期终结机制关掉了。
设计提示
**安全特性之间的交叉审计不能省。**SLAM 的深层教训是：新硬件特性的安全评估不能只在本特性的威胁模型内进行，还必须考虑该特性与所有已知漏洞的交互。LAM 的设计者在提案时评估了"LAM 是否引入新的内存破坏 primitive"（答案：否，tag 被硬件忽略）、"LAM 是否影响虚拟化语义"（答案：可通过 VMCS 控制）等——但没有评估"LAM 会不会放大现有 Spectre gadget 的威力"。这个盲区不是技术上的困难，而是评估框架的盲区：安全特性提案通常由密码学/形式化团队评审，而他们与侧信道研究社区的交集在 2020 年代中期仍不足。这类事故的修复不是单个补丁能解决的——它需要组织架构层面的变革，例如在每次新 ISA 扩展提案时强制"侧信道交叉审计"章节（类似 Intel 在 2024 年开始试行的 STORM 流程，即 Side-channel Threat Observation & Review Method）。
**为什么 SLAM 只放大了 Spectre v1 而不是 Meltdown？**一个敏锐读者可能会问：既然 LAM 放宽了 canonicality 检查，为什么它不同样放大 Meltdown（50.3.3 节）？答案在于 Meltdown 的触发机制本质上依赖 fault-on-access（kernel page 的 U/S bit fault），而 fault 在 LAM 启用前后都会照常触发——LAM 只影响地址合法性检查，不影响页表权限检查。这个区别说明 SLAM 不是一个通用的"所有瞬态攻击都会被放大"的元漏洞，而是专门放大那些依赖 canonical gap 来做早期终结的 Spectre v1 变种。换句话说，SLAM 与现有漏洞的交互是有选择性的，这让它的威胁面更难在提案阶段被完整预测——也更凸显为什么"交叉特性审计"不能只看表面关联，而必须深入到每个漏洞的具体触发链。
**暂时退场而非修复。**Linux 内核维护者在 SLAM 披露后做出了一个罕见的决定——暂停合并 LAM 的内核支持（2023 年底），直到 Intel 能给出架构级的 SLAM 缓解方案。这是整个 x86 历史上少有的"安全特性被安全问题回滚"的案例。Intel 的后续方案是给 LAM 增加一个IA32_CET_S.SLAM_MITG MSR，在内核态自动把 tag bit 参与到推测路径的 canonicality 检查中，但会损失 LAM 的部分设计收益。这个故事还没结束——截至本书截稿（2026 年），Linux 主线仍只合并了 LAM-U48 的严格子集。
**类比：ARM TBI 的类似担忧。**ARM 的 Top-Byte Ignore（TBI）特性在 ARMv8.0 起就存在（远早于 LAM），也允许用户态/内核态的 VA 高 8 bit 不参与翻译。ARM 社区在 SLAM 披露后立即对 TBI 做了回溯审计，结论是：TBI 在 AArch64 上确实存在类似的 gadget 空间放大，但由于 AArch64 原本的 canonical gap 范围本来就较 x86 小（48 vs 47 位 VA），放大效应只有 倍（vs SLAM 的 倍）；加上 ARM 的 Spectre 硬件防御自 Cortex-X3 起已经把所有非架构可见 load 的 fetch squash 窗口缩至 10 cycle，实际可利用性较低。但 ARM 还是在 Cortex-X5 设计阶段加入了"推测路径强制 full-width canonicality check"的选项位。这说明 SLAM 的教训正在被所有主要 ISA 吸收——它不是 Intel 独有的事故。
**元教训：新硬件特性不能"自证安全"。**SLAM 的案例还揭示了一个更深层的方法论问题：新硬件特性的安全评估在历史上一直倾向于在自己的威胁模型内证明安全——LAM 的提案文档（2020 年 Intel 公开的 spec）只证明了"tag 不影响地址翻译正确性"、"tag 不泄漏给用户态"等自身属性，但完全没有考虑"LAM 是否会改变已知漏洞的可利用性"。这种"模块化"的安全论证在独立特性之间是合理的，但硬件特性从来不是独立的——它们共享流水线、共享缓存、共享预测器。一个在自身模型下安全的特性，完全可以成为另一个漏洞的放大器。SLAM 之后，Intel 将"交叉特性侧信道审计"（cross-feature side-channel audit）列为 ISA 扩展提案的必选环节，提案者必须枚举该特性与现有所有公开瞬态执行漏洞（Spectre v1/v2, MDS, Retbleed, GoFetch 等）的交互路径，并给出定量分析。这是 2020 年代硬件安全工程化的一个重要拐点。
GhostRace
如果把前面七种攻击的共同点概括为"瞬态执行 + 微架构副作用"，那么 2024 年 VUSec 披露的 GhostRace（CVE-2024-2193）又往深处凿了一层——它把瞬态执行与并发数据竞争（data race）合成为一个新原语："Speculative Race Condition"（SRC）。GhostRace 让 Linux 内核里原本因 Race 窗口过窄而难以利用的 UAF（Use-After-Free）bug 突然变得易于利用——因为瞬态执行提供了一个"免费的"无限宽 race 窗口。
关键观察：spinlock 在瞬态路径上可以被"偷渡"。Linux 内核的 spinlock 实现（qspinlock / ticket spinlock）在架构语义上保证：LOCK CMPXCHG 获取锁之前，临界区内的任何访存都不会 architecturally 可见。但在推测执行流水线上，条件分支控制的锁获取（典型模式：while (atomic_cmpxchg(...) != 0) cpu_relax()）会被分支预测器猜测为"锁获取成功"——即使架构上 CMPXCHG 还没有完成，瞬态路径已经进入了临界区，瞬态内的 load/store 看到了被临界区保护的对象。如果这些 load 解引用了一个悬空指针（UAF），悬空指针的解引用就在瞬态路径上发生，其 Cache 副作用被攻击者观察。
要把 GhostRace 的穿透机制讲清楚，需要回到 x86/ARM 的内存序 + 推测执行的正交性：
LOCK CMPXCHG（x86）和LDAXR/STLXR（ARM LL/SC）的架构语义是：在该指令 retire 之前，其后续访存不得对外可见。但该保证只作用于架构可见的访存路径：store buffer 里的 store 必须等 CMPXCHG retire 才 drain 到 LFB；load 队列里的 load 的 retirement 必须在 CMPXCHG retirement 之后。
Cache fill 不是"架构可见访存"——它是一个微架构副作用，由 LD μop 发射阶段触发（即使该 LD 将来会被 squash）。内存序的保证不覆盖 Cache fill。
于是推测执行沿着"获取锁成功"的分支预测，发出 LD，该 LD 触发 Cache fill；即使后来 CMPXCHG 判定锁其实没拿到、整段瞬态被 squash，Cache 已经填上了。
根因：**锁的内存序约束只约束架构可见行为，但 Cache fill 是微架构不可见行为。**瞬态执行在这两层之间钻了空子。修复方向是把"LOCK 语义"下推到微架构：例如在推测路径上也禁止 Cache fill 直到 CMPXCHG retire——这等价于在每个锁获取点都插 LFENCE，性能代价巨大；或者更精细地只在 kernel-mode 的 spinlock 获取点插桩，这是 Linux 在 2024 年初采纳的补丁方向。
:::
**为什么这是 UAF 利用的跃迁。**内核 UAF 在正常情况下利用难度很高：需要攻击者精确控制"释放对象"和"解引用 stale 指针"两个操作之间的窗口（通常 100 ns），期间还要让 heap spray 把攻击者控制的值放到释放后的位置。GhostRace 让这一切变得免费——瞬态路径不需要真实的时间窗口，攻击者只要能让代码路径架构上走到过 freeanduse 序列，就可以在其中任何 commit 之前的瞬态路径上触发 stale pointer 的解引用。VUSec 的论文展示了这把 Linux 内核里十多个已知"难利用"的 UAF bug 升级为"可靠利用"。
**典型内核 gadget。**在 Linux 4.x–6.x 中，以下模式随处可见：
// drivers/net/xxx.c 风格的 RX handler
spin_lock(&priv->lock);
if (priv->state == RUNNING) { // 此处 BP 预测 taken
struct skb *cur = priv->cur; // 瞬态路径上的 load
cur->data[0] = priv->mac[0]; // 瞬态 store（不提交但 fill L1）
process_skb(cur);
}
spin_unlock(&priv->lock);即使另一个 CPU 通过某个 race 已经调用了 free(priv->cur) 而让 priv->cur 变成 stale 指针，传统利用需要精确让这个 free 发生在 if (priv->state == RUNNING) 判断之后但 cur->data[0] = ... 执行之前——这个窗口通常极窄。但 GhostRace 让"传统利用"变得不必要：瞬态路径不关心真实时序，只要 priv->cur 在瞬态 load 时是 stale 的，整条瞬态链就能把 stale 指针内容编码到 L1。这把以往许多"理论上可利用但实际 race window 过窄"的 UAF bug 一举变成实际威胁。
**防御代价不菲。**VUSec 与 Linux 社区合作的缓解补丁在每个 spinlock 的快路径上增加一条 LFENCE（x86）或 DSB SY（ARM）。基准测试显示：kernelheavy 工作负载（Redis、Nginx、I/O 密集数据库）IPC 下降 3%–5%；compute-heavy 工作负载几乎无影响（因为它们很少进内核）。这是一个相对温和的代价，但它提醒我们：每一层曾被认为"纯架构"的同步原语（锁、屏障、transaction），在深度推测执行下都可能需要微架构级加固。
**更上层的影响：用户态 lock-free 数据结构。**GhostRace 的根因不止影响内核 spinlock。任何依赖"compare-and-swap 分支后才能安全访问数据"的用户态无锁数据结构——hazard pointers、RCU、epoch-based reclamation——在架构上都有类似的推测穿透可能。2024 年底一篇后续论文（GhostRace++）证明 liburcu 在 Intel Raptor Lake 上确实存在同类型的 UAF-via-spec 漏洞，但利用窗口比内核场景短约 10（因为用户态的 context switch 更频繁地冲走瞬态路径上的 LDQ 条目）。这不是一个已经关闭的问题，而是一条正在活跃研究的攻击线。
**硬件级的彻底修复方向。**长远的硬件方案是把 LOCK 前缀或 LL/SC 序列升级为推测屏障：处理器在解码到 LOCK CMPXCHG 时，自动把其后续 load 的 spec_bit 与 CMPXCHG 的 retirement 事件绑定，retirement 之前不允许该 spec 路径的 LDQ 条目向 L1 发 fill 请求。这会把原本"LOCK 只约束架构可见访存"的语义下推到微架构层，代价是每个无争用锁获取增加 3–5 cycle 延迟。Intel、AMD、ARM 三家在 2025 年的多个会议上都公开讨论过相关扩展（Intel 暂称为 "LFENCE-ON-LOCK"），但都尚未在量产硅上落地。
瞬态执行攻击的全景对比
把 50.3.1 节–50.3.13 节 涉及的 12 个攻击放进同一张表，可以一眼看出 2018–2024 年瞬态执行攻击面的演化轨迹。表 表 50.6 按瞬态窗口来源、数据源、威胁模型三条正交轴对它们做了分类。
| 攻击 / CVE | 年份 | 代际影响 | 瞬态窗口来源 | 数据源 | 威胁模型 | 硬件修复 | IPC 损失 |
|---|---|---|---|---|---|---|---|
| Spectre v1 / 2017-5753 | 2018 | Intel/AMD/ARM 全系 | 分支预测 (PHT) | Cache | 同进程 / 跨域 | 新硬件 (SLH 编译器) | 1–3% |
| Spectre v2 / 2017-5715 | 2018 | Intel/AMD/ARM 全系 | 分支预测 (BTB) | Cache | 跨特权级 | 微码 (IBRS/IBPB) | 5–30% |
| Meltdown / 2017-5754 | 2018 | Intel 2011–2018 | 异常延迟 | L1D Cache | 跨特权级 | 新硬件 (KPTI+硬件) | 0–5% |
| Foreshadow / 2018-3615 | 2018 | Intel w/ SGX | 异常延迟 (L1TF) | L1D | 跨 VM / SGX | 新硬件 (L1D flush) | 2–10% |
| MDS (4 合并) | 2019 | Intel 2011–2019 | TSX abort / fault | LFB/SB/Load Port | 跨 SMT / 跨域 | 微码 (MD_CLEAR) | 3–8% |
| LVI / 2020-0551 | 2020 | Intel SGX | 异常延迟 | LFB (注入方向) | 同 SGX | 新硬件 + LFENCE | 2–19 (SGX) |
| Retbleed / 2022-29900 | 2022 | Intel/AMD Zen1–2 | RSB 下溢 BTB | Cache | 跨特权级 | 微码 + RSB stuffing | 12–39% |
| Inception / 2023-20569 | 2023 | AMD Zen 1–4 | 瞬态内 BTB 训练 | Cache | 跨特权级 | 微码 IBPB 加强 | 3–10% |
| Downfall / 2022-40982 | 2023 | Intel 6–11 代 | gather μop 并行 | SIMD 临时寄存器 | 跨 SMT | 微码 (串行化) + 新硬件 | 5–50% |
| iLeakage | 2023 | Apple M1/M2 + Safari | 分支预测 | Cache | 跨 origin (浏览器) | WebKit SLH + 新硬件 DIT | 3–8% (浏览器) |
| GoFetch | 2024 | Apple M1/M2/M3 | DMP 预取器 | Cache | 同 SMT / 同核 | 新硬件 (DIT bit) | 5–10% (DIT 开) |
| SLAM | 2023 | Intel SPR (LAM enabled) | 分支预测 (放大) | Cache | 跨特权级 | 架构 (LAM 暂缓) | N/A |
| GhostRace / 2024-2193 | 2024 | Intel/AMD/ARM 内核 | 分支预测 (锁路径) | Cache | 跨特权级 (UAF) | 软件 LFENCE + 内核 | 3–5% (kernel-heavy) |
2018–2024 年瞬态执行攻击全景矩阵
**观察 1：瞬态窗口来源的泛化。**最早的 Spectre/Meltdown 只用两种窗口——分支预测与异常延迟。2019 年后新攻击不断扩展这张列表：TSX abort（MDS/TAA）、RSB 下溢（Retbleed）、瞬态内训练（Inception）、数据依赖预取（GoFetch）、推测性锁进入（GhostRace）。每一种新窗口来源都对应处理器某个以前被认为"无害"的优化机制。
**观察 2：数据源的扩张。**L1D Cache 只是瞬态攻击的第一代数据源。2019 年 MDS 把攻击面扩展到 LFB/SB/Load Port；2023 年 Downfall 进一步到 SIMD 执行单元的内部临时寄存器；2024 年 GoFetch 证明连数据内容本身都可以经 DMP 成为侧信道。这个趋势指向一个尚未公开披露但已被学术社区讨论的可能方向：L1I Cache 的瞬态 prefetch、uop cache 的命中率波动、甚至 retirement FIFO 的占用模式，都可能成为下一代泄露源。
**观察 3：威胁模型向"同 SMT / 同核"收紧。**早期攻击（Spectre v1/v2, Meltdown）的最大威胁在跨特权级泄漏；MDS 把威胁拉到跨 SMT；Downfall 和 GoFetch 进一步进到同 SMT 同进程内——这反映出攻击面向更细粒度共享资源下潜。工业界对 SMT 的态度也因此逐步改变：Google、AWS 在 2018–2020 年间逐步在敏感租户上禁用 SMT；Apple 甚至从未在 Apple Silicon 上引入 SMT，部分原因正是避开这整类跨 SMT 攻击面。
时间线：攻击披露 vs 硬件修复。
| 攻击 | 披露日期 | 首批微码缓解 | 首批硬件级修复 |
|---|---|---|---|
| Spectre v2 | 2018-01 | 2018-01 (IBPB) | 2019 Q3 (Coffee Lake R, eIBRS) |
| Meltdown | 2018-01 | 2018-01 (KPTI) | 2019 (Cascade Lake, 硬件 KAISER) |
| MDS | 2019-05 | 2019-05 (MD_CLEAR) | 2020 (Ice Lake, 硬件 LFB flush) |
| LVI | 2020-03 | 2020-03 (SDK) | 2021 (Ice Lake, LFB domain tag) |
| Retbleed | 2022-07 | 2022-07 (RSB fill) | 2023 (Raptor Lake, 硬件 eIBRS+) |
| Downfall | 2023-08 | 2023-08 (串行化) | 2024 (Meteor Lake, gather zero) |
| Inception | 2023-08 | 2023-08 (IBPB+) | 2024 (Zen 5, BTB opcode-tag) |
| GoFetch | 2024-03 | 无 | 2023-10 (M3, DIT bit，披露前已在芯片内) |
| GhostRace | 2024-03 | 2024-03 (kernel LFENCE) | 未定 |
**为什么每次新攻击都需要 6–18 个月才能完全修复？**答案分三层：
微码层（几小时 – 几周）：微码缓解本质上是在原有硬件逻辑上加一层"串行化 / flush / bypass"开关。它通常是"关大水闸"的粗粒度方案——例如 Downfall 的 gather 串行化，会把整个 gather 吞吐降一半。它可以在攻击披露后几小时到几周内发布，但性能代价常常不可接受，需要后续的 refinement。
软件层（几天 – 几个月）：Linux 内核、编译器、虚拟机监控器都需要适配新的缓解接口（SLH、Retpoline、KPTI、IBPB 触发点等）。这里的挑战是"不要过度触发"——例如 Retpoline 只需在用户内核切换时启用，但早期的粗糙实现在每次函数调用都插桩，IPC 损失直逼 30%。打磨到可接受范围需要几个月。
硬件层（1–3 年）：真正消除根因的硬件修复需要下一代处理器——因为流片周期本身就是 18–36 个月。Spectre v2 的 eIBRS 硬件支持在 Coffee Lake Refresh（2019 Q3）才上市，距离 2018 年 1 月披露近 20 个月。这是整个瞬态攻击防御体系最漫长的一层。
**攻防不对称带来的结构性风险。**披露 vs 修复的时间差反映了一个结构性问题：攻击的设计与实现可以由少数学术团队在几个月内完成，但防御的推广到全部生产系统需要跨芯片厂商、OS 厂商、云服务商、企业 IT 部门协同，时间量级差一两个数量级。这意味着瞬态执行攻击带来的安全风险不会在某一天被"彻底解决"——它会作为一种持续的管理性风险存在于整个 2020 年代。面向 2030 年的处理器设计，必须在架构层就系统性地纳入"微架构状态可回滚"或"微架构状态按安全域分区"这类正交原语（见 50.5.1 节 与 50.5.3 节 的讨论），而不是继续以打补丁的方式追赶下一次披露。
**观察 4：防御机制的性能复合开销。**值得单独指出的一点是，上面表格的"IPC 损失"列并不是各攻击单独打补丁的数字，而是累积的。当一台真实云服务器同时启用 Spectre v2（IBRS）、MDS（MD_CLEAR）、Retbleed（RSB filling）、Downfall（gather 串行化）、GhostRace（kernel LFENCE）全套防御时，总性能损失并非各项相加——因为某些机制共享触发点（如 IBRS 和 MD_CLEAR 都在 ring transition 时生效），有些互相遮蔽（gather 串行化减少了高 IPC 路径的总量，让 IBRS 的相对影响缩小）。Google 2023 年在 Borg 集群上的实测数据显示：所有公开瞬态缓解全开时，典型 web 服务（占比 60% 的工作负载）总 IPC 损失 18%–25%，HPC 科学计算损失 30%–45%。这是一个巨大的隐藏成本——在数据中心规模下，相当于每年数十亿美元的额外计算支出。对小厂商和边缘计算场景，"选择性关闭部分缓解"已经成为一种常见的风险管理决策。
**观察 5：硬件修复的"冷启动"挑战。**即使厂商在新硅上集成了硬件级修复（如 Apple M3 的 DIT bit），实际启用还受制于软件生态。DIT 在 macOS 14 上需要应用主动声明才会启用——默认关闭。这意味着一条硬件修复从流片到"被大多数用户实际使用"往往还要再等 2–3 年——软件生态的迁移速度是另一个瓶颈。这条教训对芯片设计者的启示是：防御机制的易用性和默认值与防御机制本身同样重要。最强的硬件缓解如果默认关闭、需要应用主动声明，它在实战中的覆盖率可能比软件补丁还低。
设计提示
给处理器设计者的三条通用启示。回顾这 12 个攻击的演化，可以抽象出三条对 2030 年设计决策直接有用的经验法则：（1）任何在取指-预测-发射-执行-提交五阶段中跨阶段共享的微架构资源，都是潜在的侧信道通道——Cache、LFB、SB、BP、DMP、execution port temp reg，无一例外；（2）"特定优化在 X 场景下无害"这种局部结论在深度推测流水线下一律不可信——必须把所有微架构优化放进统一的侧信道威胁模型（即 ch51 的 STORM 式审计框架）里重新评估；（3）攻击的创新速度 防御的部署速度这一结构性鸿沟无法靠更努力的响应缩小，只能靠架构原语——比如"所有 speculation 必须在安全域 tag 下运行"、"所有微架构 state 必须带有 undo log"——从根本上移除大半个攻击面。Hennessy & Patterson 在第 6 版前言里对"安全成为架构 first-class 关注点"的预言，在 2024 年已是共识而非前瞻。
其他侧信道
除了Cache和瞬态执行攻击之外，处理器中还存在多种其他微架构侧信道。这些侧信道利用不同的共享资源，虽然通常比Cache侧信道的带宽低或利用难度更大，但它们提供了正交的攻击面——可能绕过专门针对Cache侧信道设计的防御措施。
TLB侧信道
TLB（Translation Lookaside Buffer）是处理器用于加速虚拟地址到物理地址翻译的Cache。与数据Cache类似，TLB也存在命中与缺失的时间差异，可以被利用为侧信道。
TLB侧信道的原理。TLB命中时，地址翻译在1–2个周期内完成（通常被流水线隐藏）；TLB缺失时，处理器需要进行页表遍历（page table walk），延迟为10–100个周期（取决于页表层级和页表数据是否在Cache中）。攻击者可以通过类似Prime+Probe的技术来探测TLB状态：
（1）**Prime阶段。**攻击者访问大量映射到不同TLB条目的页面，将目标TLB set填满自己的翻译条目。
（2）**Probe阶段。**等待受害者执行后，攻击者重新访问之前prime的页面，测量访问时间。如果受害者访问了映射到同一TLB set的页面，攻击者的某些TLB条目会被驱逐，导致probe阶段产生TLB缺失。
TLB侧信道的监控粒度。与Cache侧信道的64字节粒度不同，TLB侧信道的粒度为页面级别（4 KB或更大）。这意味着TLB侧信道只能推断受害者访问了哪些页面，而不能精确到页面内的哪个偏移。对于某些攻击场景（如推断受害者访问了代码的哪个函数/模块），页面级粒度已经足够；但对于需要字节级精度的攻击（如AES密钥恢复），TLB侧信道的粒度通常不够。
TLB侧信道的特殊价值。TLB侧信道在以下场景中具有特殊价值：（1）对抗Cache随机化——Cache随机化打乱了地址到Cache set的映射，但TLB的索引通常不受Cache随机化的影响。攻击者可以通过TLB侧信道推断受害者访问了哪些页面，从而获取粗粒度的内存访问模式信息。（2）SGX enclave攻击——Intel SGX（Software Guard Extensions）将敏感代码和数据放在加密的enclave中，操作系统无法直接读取enclave的内容。然而，控制操作系统的攻击者可以操纵enclave的页表映射，制造目标TLB缺失，然后通过页面错误或A/D位来追踪enclave的页面级访问模式。这种攻击被称为受控信道攻击（controlled-channel attack）。
防御措施。（1）TLB分区（TLB partitioning）——在SMT环境中，将TLB条目按线程/安全域进行硬分区，防止跨域的TLB驱逐。Intel在Alder Lake及以后的处理器中对L1 iTLB和dTLB进行了逻辑分区。（2）TLB随机化——类似Cache随机化，对TLB的索引函数进行随机化。（3）PCID/VMID隔离——在TLB条目中加入PCID/VMID标签，不同域的TLB条目不会互相干扰。
案例研究 11 — 受控信道攻击对SGX enclave的威胁
2015年，Xu等人提出了受控信道攻击（Controlled-Channel Attack），展示了恶意操作系统如何通过页表操纵来精确追踪SGX enclave的内存访问模式。
在SGX的威胁模型中，操作系统被视为不可信的——enclave的代码和数据在内存中是加密的，操作系统无法直接读取。然而，操作系统仍然控制页表。攻击步骤如下：
（1）操作系统将enclave使用的所有页面标记为不存在（清除页表项的Present位）。
（2）当enclave执行并访问某个页面时，由于该页面被标记为不存在，处理器产生页面错误，控制权转移到操作系统。
（3）操作系统记录产生页面错误的虚拟地址（即enclave正在访问的页面），然后将该页面标记为存在并恢复enclave执行。
（4）重复上述过程，操作系统可以记录enclave的完整页面级访问序列。
Xu等人利用这种技术成功攻击了enclave中的文本处理程序（libjpeg和FreeType），通过分析代码页面的访问序列推断出正在处理的文本内容。后续研究进一步利用Intel处理器页表项中的访问位（Access bit）和脏位（Dirty bit）来减少页面错误的频率，实现更隐蔽的监控。
这一攻击对处理器设计的启示是：即使数据在内存中被加密（如SGX的内存加密引擎MEE），地址访问模式本身也是敏感信息。真正安全的执行环境需要在硬件层面保护地址访问模式不被操作系统观察到——这就是不经意RAM（Oblivious RAM, ORAM）技术在硬件中应用的动机。
执行端口侧信道
执行端口侧信道（Execution Port Side Channel）利用超标量处理器中功能单元的竞争来推断受害者正在执行的指令类型。
攻击原理。在现代超标量处理器中，不同类型的指令被分配到不同的执行端口（execution port）。例如，在Intel Skylake处理器中，简单ALU操作可以在端口0、1、5、6上执行，而整数除法只能在端口0上执行，向量乘法只能在端口0和1上执行。当两条指令需要使用同一个端口时，其中一条必须等待另一条完成——这就是端口竞争（port contention）。
2018年，Aldaya等人展示了PortSmash攻击：在SMT处理器上，攻击者线程和受害者线程共享同一物理核心的执行端口。攻击者持续执行绑定到特定端口的指令，并测量这些指令的执行吞吐量。当受害者也执行使用同一端口的指令时，竞争导致攻击者的吞吐量下降。通过监测不同端口上的吞吐量变化，攻击者可以推断受害者正在执行哪种类型的指令。
信息泄露的粒度。执行端口侧信道的信息泄露粒度为指令类型级别——攻击者可以区分受害者正在执行ALU操作、乘法、除法、内存访问还是浮点运算等。这种粒度对于直接恢复密钥来说通常不够精细，但可以泄露控制流信息——例如在RSA的平方-乘（square-and-multiply）算法中，攻击者可以通过区分乘法操作和平方操作来推断密钥的各个比特位。
**PortSmash的实验结果。**Aldaya等人在Intel Skylake处理器上利用PortSmash攻击了OpenSSL的ECDSA P-384实现，成功恢复了完整的私钥。攻击利用了P-384标量乘法中的条件分支——不同的密钥位导致不同的代码路径被执行，这些代码路径使用不同的执行端口组合，从而被PortSmash检测到。
防御措施。（1）禁用SMT——最直接但代价最高的防御，消除了共享执行端口的攻击面。（2）端口调度随机化——在功能单元调度中引入随机性，使得指令到端口的映射不再确定性。（3）恒定时间编程——确保密码学代码的执行路径和端口使用模式不依赖于秘密数据。这需要密码学库的开发者在指令级别仔细审计代码，确保所有分支和操作类型选择都与秘密数据无关。
硬件描述 13 — SMT环境中的资源隔离挑战
SMT（同时多线程）是执行端口侧信道和许多其他微架构侧信道的主要放大器。在SMT处理器中，两个逻辑线程共享同一物理核心的几乎所有微架构资源：
| 微架构资源 | 共享/私有 | 侧信道风险 |
|---|---|---|
| 执行端口 | 共享（竞争） | 高（PortSmash） |
| L1 Data Cache | 共享（竞争） | 高（Prime+Probe） |
| L1 Instruction Cache | 共享（竞争） | 中 |
| L2 Cache | 共享 | 高 |
| TLB | 共享（竞争） | 中 |
| 分支预测器（BTB/PHT） | 共享 | 高（Spectre v2） |
| 填充缓冲区（LFB） | 共享 | 高（MDS） |
| 存储缓冲区 | 分区/共享 | 中–高 |
| ROB | 分区 | 低 |
| 架构寄存器文件 | 私有 | 无 |
从安全角度看，SMT的理想实现应该是对所有共享资源进行严格分区——每个逻辑线程获得每种共享资源的固定份额，彼此之间不存在竞争。但这会降低SMT的核心优势：灵活的资源共享允许一个繁忙的线程使用另一个空闲线程的资源份额，提高总体吞吐量。完全分区后，SMT的吞吐量提升从典型的20%–30%下降到10%–15%，削弱了SMT的价值。
折中方案是选择性分区：对安全风险最高的资源（如BTB、LFB）进行严格分区或添加安全域标签，而对风险较低或分区代价过高的资源（如L1 Cache、执行端口）采用监测和缓解策略。Intel从Ice Lake开始在BTB中加入了线程标识，AMD在Zen 3中对SMT线程的BTB和PHT进行了更严格的隔离。
电源侧信道
电源侧信道（Power Side Channel）利用处理器在执行不同操作时功耗的差异来推断正在处理的数据。电源侧信道传统上属于物理攻击的范畴——攻击者需要物理接触目标设备，使用示波器或电磁探针测量功耗或电磁辐射。然而，近年来的研究表明，软件也可以利用处理器内部的功耗监控接口来实现类似的攻击，这使得电源侧信道成为了一种远程可利用的威胁。
**功耗与数据的关系。**CMOS电路的动态功耗与数据相关，主要通过两种机制：
（1）**汉明权重（Hamming Weight）模型。**CMOS电路中，输出为"1"的门比输出为"0"的门消耗更多的功率（因为需要对负载电容充电）。因此，处理器在处理值0xFF（8个1）时的瞬时功耗高于处理值0x01（1个1）时的功耗。数据值中"1"的个数（汉明权重）与功耗之间存在近似线性关系。
（2）**汉明距离（Hamming Distance）模型。**当寄存器或总线上的值发生变化时，发生翻转的位（从0变为1或从1变为0）的数量决定了翻转产生的动态功耗。翻转位数越多，功耗越高。汉明距离模型在预测数据总线和寄存器文件的功耗时特别准确。
基于RAPL的软件电源侧信道。Intel处理器提供了RAPL（Running Average Power Limit）接口，允许软件通过MSR（Model-Specific Register）读取处理器各个功耗域（CPU核心、非核心部分、DRAM等）的累计能耗。RAPL的采样率约为每毫秒一次，精度约为1 mW。
2020年，Lipp等人展示了PLATYPUS（Power Leakage Attacks: Targeting Your Protected User Secrets）攻击：利用RAPL接口的功耗读数，在不需要物理接触的情况下实现了类似传统功耗分析攻击的效果。攻击者可以通过以下步骤提取密钥：
（1）在受害者执行加密操作的同时，持续读取RAPL的功耗值。
（2）收集大量功耗轨迹（每次加密一个轨迹）。
（3）使用差分功耗分析（Differential Power Analysis, DPA）或相关功耗分析（Correlation Power Analysis, CPA）技术，将功耗轨迹与密钥候选值进行相关性分析，找出相关性最高的密钥值。
PLATYPUS的实验表明，利用RAPL接口可以在几分钟内恢复AES-NI硬件加密指令处理的密钥，甚至可以恢复SGX enclave中的密钥。
DVFS侧信道。另一种软件可利用的电源侧信道来自DVFS（Dynamic Voltage and Frequency Scaling）机制。当处理器的功耗接近TDP（热设计功耗）限制时，DVFS会降低频率以控制功耗。攻击者可以通过观察处理器频率的变化（通过测量指令执行速率）来推断受害者的工作负载特征和数据模式。
2022年的Hertzbleed攻击正是利用了这种机制。Hertzbleed的关键发现是：Intel和AMD的处理器在执行某些密码学操作时，由于数据依赖的功耗差异，DVFS系统会将处理器调整到不同的频率档位。例如，在执行SIKE（Supersingular Isogeny Key Encapsulation）密钥交换时，不同的密钥位导致不同的中间计算值，这些值的汉明权重差异会导致约100 mW的功耗差异。虽然这个功耗差异本身很难远程测量，但DVFS将其转化为了可观测的频率差异——处理器可能在4.9 GHz和5.0 GHz之间切换。频率差异直接导致了执行时间差异——在5.0 GHz下执行的操作比4.9 GHz下快约2%。攻击者通过网络测量多次密钥交换的响应时间，利用统计方法检测这些微小的时间差异，最终恢复了完整的SIKE私钥。
TLB侧信道的微架构分析
TLB侧信道的攻击粒度为页面级别（通常4 KB），比Cache侧信道的Cache行级别（64字节）粗得多。但TLB侧信道有一个独特优势：TLB的替换策略通常比Cache更简单（如直接的全相联LRU或伪LRU），使得攻击者可以更精确地推断受害者的页面访问模式。
TLB侧信道的典型攻击方法是TLB Prime+Probe：
Prime：攻击者访问足够多的不同页面（超过TLB的条目数），将TLB完全填充为自己的地址翻译条目。
等待：让受害者执行，受害者的页面访问会驱逐TLB中攻击者的某些条目。
Probe：攻击者重新访问之前Prime的所有页面，测量每次访问的时间。如果某个页面的访问时间增加（TLB miss），说明受害者在等待期间访问了一个与该TLB条目冲突的页面。
TLB侧信道对SGX enclave特别有效。SGX enclave的代码和数据运行在受保护的enclave内存中，操作系统无法直接观测enclave的行为。但操作系统控制着页表——通过操纵页表的"accessed"位或故意制造页面错误（将enclave的某些页面标记为不可访问），操作系统可以以页面粒度跟踪enclave的内存访问模式。这种基于页表的攻击被称为受控侧信道攻击（Controlled-Channel Attack）。
执行端口竞争侧信道
在支持SMT（同步多线程/超线程）的处理器中，同一物理核心上的两个逻辑线程共享执行端口（execution port）。当攻击者线程和受害者线程同时运行在同一物理核心的两个逻辑线程上时，攻击者可以通过测量自己的指令执行延迟来推断受害者正在使用哪些执行端口——从而推断受害者正在执行什么类型的指令。
例如，如果攻击者持续执行整数乘法指令（使用端口1），当受害者也执行乘法指令时，攻击者会观测到自己的乘法延迟增加（因为端口1被竞争）。通过系统地探测所有执行端口的竞争情况，攻击者可以重建受害者的指令执行痕迹。
端口竞争侧信道的精度可以达到单条指令级别（区分不同类型的指令），但需要攻击者和受害者在同一物理核心上运行（SMT场景）。防御方法包括：（1）禁用SMT（性能代价约2030%）；（2）在安全敏感的工作负载运行时暂时将SMT伙伴线程空闲化；（3）在硬件中实现执行端口的严格分区（代价是两个线程的有效执行资源减半）。
电源侧信道
Hertzbleed的深刻意义在于它证明了：即使程序本身是恒定时间的（执行的指令序列和内存访问模式完全不依赖秘密数据），DVFS仍然可以将数据依赖的功耗泄露转化为时间泄露。这打破了恒定时间编程的一个基本假设——程序的执行时间只取决于指令序列而不取决于数据值。
防御措施。（1）限制RAPL接口的访问权限——将RAPL的MSR读取限制为仅root用户可用。Linux在5.10版本后默认限制了非特权用户对RAPL的访问。（2）降低RAPL的精度——通过在RAPL读数中加入噪声或降低更新频率来减少可利用的信息。Intel在部分微码更新中降低了RAPL的能耗计数器精度。（3）恒定功耗设计——在密码学指令（如AES-NI）的实现中，确保功耗与处理的数据无关。这需要在电路级别使用数据无关（data-oblivious）的设计风格，如双轨逻辑（dual-rail logic）或预充电逻辑，但这会增加约2倍的面积和功耗。（4）禁用基于负载的频率调整——在安全敏感的环境中，固定处理器频率以防止Hertzbleed类攻击，代价是牺牲了DVFS的功耗优化效果。
性能分析 9 — 侧信道防御的累积性能代价
在实际的生产环境中，处理器通常需要同时启用多种侧信道防御措施。这些措施的性能代价会累积叠加，导致显著的总体性能损失。以一个典型的Linux服务器（启用全部Spectre/Meltdown/MDS缓解措施）为例：
| 防御措施 | 单独性能代价 | 累积性能代价 |
|---|---|---|
| KPTI（Meltdown） | 3%–5% | 3%–5% |
| + Retpoline（Spectre v2） | 2%–5% | 5%–9% |
| + LFENCE屏障（Spectre v1） | 2%–5% | 7%–13% |
| + STIBP（SMT隔离） | 1%–3% | 8%–15% |
| + VERW清零（MDS） | 1%–3% | 9%–17% |
| + L1D刷新（VM安全） | 1%–2% | 10%–18% |
在系统调用密集型工作负载（如数据库、Web服务器）中，累积的性能代价可能达到15%–25%。这个数字相当于一到两代处理器的IPC提升——也就是说，侧信道防御措施"吃掉"了一到两代处理器的性能进步。
这正是为什么硬件级防御如此重要：Intel从Ice Lake开始在硬件中修复了Meltdown和大部分MDS漏洞，AMD的处理器在架构上就不受Meltdown影响——这使得在这些较新的处理器上，KPTI和VERW清零的性能代价大幅减少甚至可以完全消除。处理器安全的长期方向是将尽可能多的防御措施下沉到硬件中，用极小的面积代价换取几乎零性能代价的安全保证。
表表 50.9对本章讨论的主要攻击和对应防御措施进行了总结。
| 攻击类型 | 软件防御 | 硬件防御 | 典型性能代价 |
|---|---|---|---|
| Flush+Reload | 禁用页面共享/去重 | Cache分区 | 2% |
| Prime+Probe | 恒定时间编程 | Cache随机化 | 0.5%–2% |
| Spectre v1 | LFENCE/CSDB屏障 | 推测加载限制 | 5%–15% |
| Spectre v2 | Retpoline | eIBRS/IBPB | 2%–10% |
| Meltdown | KPTI | 权限前置检查 | 2%–15% |
| MDS | VERW缓冲区清零 | 缓冲区自动清零 | 1%–5% |
| Retbleed | RSB填充 | 改进RSB下溢处理 | 2%–5% |
| TLB侧信道 | ORAM | TLB分区/随机化 | 5%–20% |
| 端口竞争 | 恒定时间编程 | 禁用SMT | 20%–30% |
| 电源侧信道 | 限制RAPL访问 | 降低精度/固定频率 | 1% |
主要微架构侧信道攻击的防御措施总结
硬件防御的微架构实现
前面各节讨论了各类侧信道攻击的防御方案。本节从处理器微架构设计者的角度，深入分析几种关键硬件防御的实现细节和设计权衡。
推测执行安全的流水线重设计
解决瞬态执行攻击的根本方法是重新设计处理器的推测执行机制，确保推测执行的微架构副作用不会泄露安全敏感的信息。学术界提出了多种方案，它们在安全保证和性能代价之间处于不同的权衡点。
NDA（Non-speculative Data Access）
NDA方案的核心规则是：推测执行的load指令可以访问Cache，但其返回的数据不能被用于生成新的内存地址。换言之，推测load的数据可以被后续的计算指令（如ALU操作）使用，但不能被用作另一条load指令的地址——因为正是"数据地址Cache访问"这一链条将秘密数据编码到了Cache状态中。
NDA的微架构实现需要在发射逻辑中增加一个推测深度检查：对于每条load指令，检查其地址是否依赖于另一条尚未提交的推测load的数据。如果是，该load被暂停直到依赖的推测load被提交（推测被确认正确）。
NDA的性能代价约为38%的IPC下降——这比LFENCE屏障的代价低得多，因为NDA只限制了特定的依赖模式（loadload的地址依赖链），而不是阻止所有推测执行。
STT（Speculative Taint Tracking）
STT方案使用污点追踪（taint tracking）来标识推测执行中可能泄露信息的数据流。具体来说：
所有推测执行的load指令的结果被标记为"tainted"（受污染的）。
任何使用tainted操作数计算出的值也被标记为tainted（污点传播）。
以tainted值作为地址的load指令被暂停，直到相关的推测被确认正确（此时taint标记被清除）。
非tainted的推测load（其地址不依赖于其他推测数据）正常执行，不受限制。
STT在物理寄存器文件中为每个寄存器增加一个taint位，在旁路网络中传播taint信息。当一条指令提交时，其目标寄存器的taint位被清除。STT的性能代价约为25%的IPC下降，因为大多数推测load的地址来自已提交的（非推测的）计算，不会被暂停。
性能分析 10 — 各推测执行防御方案的性能比较
下表比较了几种推测执行防御方案的性能和安全保证：
| 方案 | IPC损失 | 防御范围 | 硬件开销 |
|---|---|---|---|
| LFENCE屏障（软件） | 10%–30% | Spectre v1 | 无 |
| Retpoline（软件） | 2%–10% | Spectre v2 | 无 |
| NDA | 3%–8% | Spectre v1 | 低（发射逻辑修改） |
| STT | 2%–5% | Spectre v1+部分v2 | 中（taint位+传播逻辑） |
| InvisiSpec | 5%–10% | 全部Cache侧信道 | 高（SB+验证加载） |
| CleanupSpec | 8%–15% | 全部Cache侧信道 | 高（推测Cache撤销） |
| KPTI（软件） | 3%–15% | Meltdown | 无硬件修改 |
| 权限前置检查（硬件） | 1% | Meltdown | 低（load单元修改） |
从表中可以看出，硬件级防御通常比纯软件防御的性能代价更低。特别是针对Meltdown的硬件修复（权限前置检查），其性能代价接近零——这是因为权限检查与Cache访问本来就可以并行进行，只需在数据转发路径中增加一个门控逻辑。这个案例充分说明了安全设计前置（security by design）的重要性——在初始设计阶段就考虑安全约束，比事后通过软件补丁修复的代价低得多。
分支预测器的安全域隔离
Spectre v2和Retbleed攻击利用了分支预测器（BTB、PHT、RSB等）在不同安全域之间的共享。安全的分支预测器设计需要在不同安全域之间实现有效的隔离，同时尽量减少对预测精度的影响。
基于上下文标识的分支预测器分区
最直接的隔离方法是在分支预测器的每个条目中加入上下文标识（Context ID），如PCID（进程上下文ID）或VMID（虚拟机ID）。只有当预测条目的上下文标识与当前执行上下文匹配时，预测才被使用。
这种方法的安全性较高，但有两个代价：（1）每个预测器条目增加了上下文标识字段的存储（816位），减少了有效的预测器容量；（2）上下文切换后，新上下文的预测器条目需要从"冷"状态开始训练，导致切换后短时间内的预测精度下降。
上下文切换时的预测器刷新
Intel的IBPB（Indirect Branch Prediction Barrier）指令在执行时清除所有间接分支预测器的状态。操作系统在进程切换时执行IBPB，确保前一个进程的BTB训练不会影响后一个进程的预测。
IBPB的代价是切换后的分支预测冷启动。测量表明，IBPB后的前10,000100,000条分支指令的预测精度显著下降（MPKI增加约25），直到预测器被新的执行模式重新训练。在上下文切换频繁的工作负载（如延迟敏感的微服务），IBPB的性能代价可达510%。因此，IBPB通常只在进程上下文切换时使用（而非每次系统调用），以限制其性能影响。
eIBRS的微架构实现
Intel的eIBRS（Enhanced Indirect Branch Restricted Speculation）是一种更精细的硬件隔离方案。eIBRS确保在不同特权级之间（用户态vs内核态）和不同VMPL（VM Permission Level）之间，间接分支预测器的预测是隔离的——低特权级的训练不会影响高特权级的预测。
eIBRS的微架构实现可能采用以下策略之一：
特权级标签：BTB条目中包含训练时的特权级。在高特权级执行时，忽略所有低特权级训练的条目。
特权级分区：BTB被物理分区为多个区域，不同特权级使用不同的区域。
密码学隔离：使用与特权级相关的密钥对BTB条目进行加密/解密，使得不同特权级的条目在逻辑上完全独立。
eIBRS的性能代价极低（1%），因为它不需要在切换时刷新预测器——它只是在预测时过滤掉不匹配特权级的条目。这使得eIBRS成为对抗Spectre v2的首选硬件防御方案（在支持eIBRS的处理器上，Retpoline不再必要）。
面向2030年的侧信道防御趋势
处理器侧信道安全是一个持续演进的领域。面向2030年代，以下防御趋势值得关注：
安全感知的微架构设计
未来的处理器在设计初期就将安全性作为核心设计目标之一（而非事后修补）。这要求微架构设计者在每个共享微架构资源（Cache、TLB、分支预测器、执行端口、填充缓冲区等）的设计中，系统性地分析其是否构成侧信道，并在安全性和性能之间做出明确的设计决策。
形式化安全验证
使用形式化方法验证处理器的微架构设计不存在信息泄露。例如，通过信息流分析（Information Flow Analysis）形式化地证明"推测执行期间的任何微架构状态变化都不依赖于安全敏感的数据"这一安全属性。虽然全芯片级的形式化验证在当前的技术水平下尚不可行，但对关键模块（如load单元、分支预测器）的形式化验证已经开始在工业界应用。
硬件辅助的运行时检测
在处理器中集成专用的安全监控硬件，通过性能计数器和行为模式分析实时检测侧信道攻击的特征（如异常的Cache miss模式、异常频率的CLFLUSH指令、异常的分支预测失败率等），并在检测到攻击时触发防御措施（如刷新共享Cache、增加噪声、通知安全管理器）。
设计提示
处理器侧信道安全的核心挑战在于：几乎所有提升性能的微架构优化都可能引入新的侧信道。推测执行提升了IPC但引入了Spectre/Meltdown；Cache层次结构减少了内存延迟但引入了Cache侧信道；SMT提升了吞吐量但引入了端口竞争和缓冲区共享的侧信道；DVFS优化了能效但引入了频率/功耗侧信道。处理器设计者面临的长期挑战是：在不显著牺牲性能的前提下，系统性地消除或缓解每种微架构优化可能带来的信息泄露。这需要安全分析成为微架构设计方法学的内在组成部分，而非事后的补救措施。
本章系统地介绍了处理器微架构中主要的侧信道攻击技术及其防御方案。从Cache侧信道到瞬态执行攻击，再到TLB、执行端口和电源侧信道，这些攻击揭示了一个核心矛盾：现代高性能处理器的每一项微架构优化（推测执行、Cache层次结构、资源共享、SMT、DVFS）都可能成为信息泄露的渠道。处理器设计师在追求性能的同时，必须系统性地分析每种优化的安全影响，并在安全与性能之间做出明智的权衡。
安全设计的层次化方法。从实践角度看，处理器安全防御应该采用纵深防御（defense in depth）的策略，在多个层次上叠加保护措施：
硬件层：在处理器设计中内建安全机制——推测执行的权限检查前置、微架构缓冲区的自动清零、分支预测器的安全域隔离、Cache随机化等。这些机制的性能代价最小（通常2%），且对软件透明。
微码层：通过微码更新部署安全补丁——VERW触发的缓冲区清零、MSR控制的IBRS/STIBP等。微码层的灵活性使得已部署的处理器可以在不更换硬件的情况下获得安全增强。
操作系统层：通过内核级防御提供系统范围的保护——KPTI、Retpoline、进程间的微架构状态清理等。
编译器层：在编译过程中自动插入安全屏障——如LLVM的Speculative Load Hardening（SLH）在推测执行路径中对load地址进行掩码，防止越界访问。
应用层：密码学库和安全敏感应用采用恒定时间编程实践，消除数据依赖的控制流和内存访问模式。
侧信道攻击的发展趋势
回顾2018年以来的侧信道攻击发展历程，可以观察到以下趋势：
攻击面持续扩大：从最初的Cache和分支预测器，扩展到TLB、执行端口、内部缓冲区、电源/频率系统。几乎每种共享的微架构资源都被证明可以作为侧信道。
攻击复杂度降低：早期的Cache侧信道攻击需要对处理器微架构有深入的了解和精密的实验设置。但随着PoC代码的公开和攻击工具的成熟，侧信道攻击的门槛显著降低。
防御与攻击的"军备竞赛"：每一种新的防御措施都会被研究者寻找绕过方法。例如，Retpoline被设计为防御Spectre v2，但Retbleed证明**
RET**指令本身也可以被攻击；eIBRS被设计为隔离分支预测器，但Inception证明非分支指令也可以触发推测执行。硬件防御逐步成熟：从早期的纯软件补丁（KPTI、Retpoline）到硬件+微码混合防御（eIBRS、VERW清零），再到新一代处理器中的原生硬件修复（Meltdown修复、MDS修复），安全防御正在逐步下沉到硬件层面，性能代价也在持续降低。
| 年份 | 漏洞名称 | 利用的资源 | 防御状态 |
|---|---|---|---|
| 2018.01 | Spectre v1/v2, Meltdown | Cache, 分支预测器 | 软件+硬件修复 |
| 2018.08 | Foreshadow (L1TF) | L1 Cache, SGX | 微码+软件 |
| 2019.05 | MDS (RIDL, ZombieLoad) | 内部缓冲区 | 微码+硬件修复 |
| 2019.11 | TAA (TSX Async Abort) | TSX, 内部缓冲区 | 微码 |
| 2020.06 | CrossTalk/SRBDS | 暂存缓冲区 | 微码 |
| 2021.03 | Spectre-BHB | 分支历史注入 | 软件+微码 |
| 2022.07 | Retbleed | RSB下溢, BTB | 微码+软件 |
| 2022.10 | SQUIP | 调度队列 | 微码 |
| 2023.08 | Inception/Downfall | 幻影推测, AVX | 微码 |
| 2024.03 | GhostRace | 推测竞态条件 | 软件 |
2018–2024年主要侧信道漏洞时间线
从表表 50.11可以看出，平均每半年到一年就有新的重要侧信道漏洞被发现。这个频率反映了一个基本事实：现代高性能处理器的微架构极其复杂（数百亿个晶体管、数千种微架构状态），在设计阶段穷举所有可能的信息泄露路径是不现实的。因此，侧信道安全将是一个持续的过程而非一次性解决的问题。
代码清单 lst:ch50-flush-reload给出了Flush+Reload攻击的核心C代码。这段代码展示了Cache侧信道攻击的基本模式：flush一个Cache行 等待受害者访问 测量reload时间 根据时间差异推断受害者是否访问了该地址。
#include <stdint.h>
#include <x86intrin.h> // __rdtsc(), _mm_clflush()
#define CACHE_HIT_THRESHOLD 80 // 周期; < 80 = L1/L2命中
#define PROBE_ARRAY_SIZE 256
#define PAGE_SIZE 4096
/* 探测数组: 256个页面, 每页4KB, 按页对齐防止预取 */
uint8_t probe_array[PROBE_ARRAY_SIZE * PAGE_SIZE];
/* Flush阶段: 将探测数组所有行逐出Cache */
void flush_probe_array(void) {
for (int i = 0; i < PROBE_ARRAY_SIZE; i++)
_mm_clflush(&probe_array[i * PAGE_SIZE]);
_mm_mfence(); // 保证flush完成
}
/* Reload阶段: 测量每个探测行的访问时间 */
int reload_and_measure(void) {
uint64_t t0, dt;
volatile uint8_t *addr;
int best_idx = -1;
uint64_t best_time = UINT64_MAX;
for (int i = 0; i < PROBE_ARRAY_SIZE; i++) {
/* 按随机顺序探测, 避免硬件预取干扰 */
int idx = ((i * 167) + 13) & 0xFF;
addr = &probe_array[idx * PAGE_SIZE];
t0 = __rdtsc();
(void)*addr; // 访问探测行
_mm_lfence(); // 序列化时间测量
dt = __rdtsc() - t0;
if (dt < CACHE_HIT_THRESHOLD && dt < best_time) {
best_time = dt;
best_idx = idx; // 命中 = 受害者访问过此行
}
}
return best_idx; // 返回受害者访问的秘密值对应的索引
}设计提示
上述代码揭示了Cache侧信道攻击的两个关键工程细节：（1）探测数组的页级间距——每个探测元素间隔一个页面（4 KB），是为了避免硬件预取器（参见第 7.0 章）在探测过程中自动将相邻Cache行加载到Cache中，从而产生虚假的命中信号。（2）随机化探测顺序——使用线性同余序列而非顺序遍历，是为了避免Cache组冲突的系统性偏差，以及避免分支预测器学习到固定的访问模式。从处理器设计者的防御视角看，降低rdtsc的精度（如Linux的prctl(PR_SET_TSC, PR_TSC_SIGSEGV)）可以增加攻击的噪声，但无法彻底阻止——攻击者可以构造替代计时器（如利用线程计数器）。真正有效的防御需要在微架构层面进行：分区Cache以消除跨安全域的共享（如Intel CAT），或在投机执行路径上延迟Cache填充（如ARM Cortex-A78的投机访问限制）。
本章分析了微架构侧信道攻击的原理和技术。第 51.0 章将转向防御端，讨论处理器设计中的硬件安全隔离机制：从Intel SGX/TDX的可信执行环境，到ARM CCA的Realm隔离，再到RISC-V的PMP和WorldGuard。我们将看到，安全防御正在从"事后补丁"演进为"设计阶段的一等约束"——新一代处理器在微架构设计的早期就需要进行威胁建模和侧信道评估，将安全成本作为与面积、功耗同等重要的设计维度。
从2018年Spectre/Meltdown到今天，处理器安全已经从一个学术课题发展为处理器设计流程中不可或缺的一环。Intel、AMD、ARM等主要处理器厂商都建立了专门的安全团队，在处理器设计的早期阶段就进行安全审计和威胁建模。可以预见，未来的处理器设计将在微架构层面提供越来越强的安全保证——不是通过牺牲性能来实现绝对隔离，而是通过精细的选择性隔离和安全感知的资源管理，在性能与安全之间找到最优的平衡点。