Cache 为什么会泄露信息#

Cache 的正常作用是复用近期访问过的数据。对同一个地址而言：

• 如果数据已经在 Cache 中，访问为 cache hit，延迟很短；
• 如果数据不在 Cache 中，需要从更低层级取回，访问为 cache miss，延迟明显更长。

一个直观类比：

• 桌面（desk） 相当于 Cache；
• 手边桌面上已有的数据，可以立刻拿到；
• 数据不在桌面上，就要去更远的位置查找，产生额外 penalty。

因此，只要攻击者能够精确计时，就可以判断某个地址对应的数据是否近期被加载进 Cache：

这就构成了一个侧信道：

1
受害者是否访问过某个地址
2
        ↓
3
该地址对应 cache line 是否命中
4
        ↓
5
攻击者测量访问延迟
6
        ↓
7
推断受害者的访存行为

攻击者读取到的首先不是“秘密内容本身”，而是秘密影响下的访问轨迹。只要把不同秘密值映射到不同的可测 Cache 位置，就能从访问轨迹反推出秘密值。

共享 Cache 与隔离边界#

Cache 会被不同执行实体共享：

• 同一核心上的不同进程或线程共享部分缓存资源；
• 不同核心可能共享 LLC（Last-Level Cache）；
• 虚拟机、容器或云租户在底层也可能竞争同一套缓存结构。

共享本来是为了性能与资源利用率，但安全上会形成问题：

• 一个进程的访问会改变 Cache 状态；
• 另一个进程可以观察这种状态变化；
• 即使两者在虚拟地址空间、权限或沙箱上相互隔离，也可能在 Cache 层面发生信息泄露。

所以，Cache 侧信道攻击的本质是：

利用共享微架构资源的可观察状态变化，绕开软件定义的安全隔离边界。

Architectural State 与 Microarchitectural State#

理解 Meltdown 与 Spectre，需要区分两类状态。

1. Architectural State（体系结构状态）

程序能够直接看到的状态，例如：

• 寄存器值；
• 已提交的内存写入；
• PC 与异常结果；
• ISA 定义的可见行为。

如果推测执行方向错误，或指令最终触发异常，处理器必须保证 architectural state 看起来仍然正确。

2. Microarchitectural State（微架构状态）

处理器为了实现高性能而维护的内部状态，例如：

• Cache line 是否存在；
• TLB 条目；
• 分支预测器历史；
• 预取器状态；
• 执行缓冲区内部状态。

问题在于：

• 错误路径上的指令可以被撤销，不提交寄存器结果；
• 非法访问最终可以触发异常，不让程序直接拿到非法数据；
• 但已经加载进 Cache 的 line 往往不会随之恢复原状。

因此，攻击的核心并非让非法结果正式提交，而是让非法或推测性的访问在 Cache 中留下痕迹。

TIP

最终的权限检查或异常处理会阻止非法结果提交，但瞬态执行产生的 Cache footprint 可能保留。不同处理器对权限检查与数据返回的具体实现时刻有所差异，architectural rollback 不等于 microarchitectural rollback

漏洞原理#

Meltdown 的关键对象是用户态与内核态之间的内存隔离。

正常情况下：

• 用户程序无权读取内核地址；
• 对内核地址的非法 load 应触发异常；
• 提交阶段之后，程序不可能从 architectural state 中得到内核数据。

Meltdown 利用的是乱序执行与异常处理之间的窗口：

• 非法 load 最终会被识别并触发异常；
• 在异常真正生效、相关指令退休之前，后续指令可能已经根据非法读出的值进行了瞬态执行；
• 后续指令将秘密值编码到 Cache 状态中；
• 即使处理器丢弃寄存器计算结果，攻击者仍能利用 Cache timing 恢复该值。

课堂讲述把它与动态调度部分直接联系起来：

• 指令先进入执行缓冲区 / reservation stations；
• 可执行的操作在结果正式按序提交前已经发生；
• 最后通过按序 retirement / commit 维持程序可见结果正确；
• 安全问题来自：被丢弃指令产生的 Cache 副作用并没有同时丢弃。

Example：probe array 编码秘密值#

示例代码逻辑如下：

1
; rcx = kernel address
2
; rbx = probe array
3

4
mov al, byte [rcx]       ; 读取内核地址中的一个字节 secret
5
shl rax, 0xc             ; rax = secret × 4096
6
mov rbx, qword [rbx+rax] ; 访问 probe_array[secret × 4096]

其中：

• rcx 指向攻击者想读取的内核地址；
• al 保存瞬态读取到的一个字节；
• probe_array 是攻击者可访问、可测时的数组；
• secret × 4096 让不同字节值对应到不同内存页，从而在 Cache 中留下容易区分的痕迹。

攻击过程可以分为四步。

1
secret = 0x41
2
访问位置 = probe_array[0x41 × 4096]

1
mov rbx, qword [rbx+rax]

1
probe_array[0 × 4096]
2
probe_array[1 × 4096]
3
...
4
probe_array[255 × 4096]

1
最快命中页的编号 = secret 的字节值

1
内核字节 → 数组索引 → Cache page → timing measurement → 恢复内核字节

漏洞复现与缓解#

这一部分具体参考slides

漏洞原理#

Spectre 的核心不是用户程序直接越权读取内核空间，而是：

攻击者操纵受害程序的分支预测行为，使受害程序在错误预测路径上瞬态访问自身可访问但不应泄露的数据，再通过 Cache 侧信道将信息带出。

它与前面动态分支预测的知识直接对应：

• BPU（Branch Prediction Unit）记录过去分支的行为；
• 处理器依据预测结果提前取指和执行；
• 如果预测正确，性能提升；
• 如果预测错误，错误路径上的 architectural results 被丢弃；
• 但错误路径产生的 Cache footprint 仍可能保留。

因此，Spectre 的攻击者不一定需要突破硬件权限检查，而是让目标程序在推测状态下自己访问并编码秘密。

Spectre 的三个阶段#

Spectre 攻击划分为三个阶段：

1. 训练分支预测单元

   攻击者使用大量合法输入，使 BPU 习惯于预测某个边界检查会通过。

2. 触发错误推测执行

   随后传入恶意越界索引。即使最终检查会失败，处理器仍可能根据训练结果暂时沿“检查通过”的路径执行。

3. 通过 Cache timing 解码秘密

   推测路径中的秘密相关访问将某个探测位置加载进 Cache。攻击者重新计时访问探测数组，即可推断秘密内容。

Example：越界检查绕过#

典型代码为：

1
if (x < array1_size) {
2
    y = array2[array1[x] * 256];
3

4
    // do something using y that is
5
    // observable when speculatively executed
6
}

正常语义下：

• 只有 x < array1_size 时才能读取 array1[x]；
• 越界的 x 应被条件判断拦截。

攻击过程中：

1. 攻击者多次提供合法 x，让 BPU 预测该条件通常为真；
2. 再提供一个恶意越界 x，使 array1[x] 指向受害者地址空间中的敏感数据；
3. 条件判断尚未真正完成时，预测执行临时进入分支体；
4. array1[x] 的秘密字节决定 array2[...] 中哪个位置被访问；
5. 预测错误后，y 等可见结果会被丢弃，但对应 array2 位置的 Cache 状态已改变；
6. 攻击者遍历并计时 array2，恢复秘密字节。

其中：

1
array2[array1[x] * 256]

起到的作用与 Meltdown 中的 probe array 类似：

1
秘密值 → 某个可区分的 Cache 位置

Spectre 缓解措施#

三类缓解手段。

1. 序列化 / 内存屏障指令

   在敏感路径上限制推测执行，例如使用类似 LFENCE 的指令，确保边界检查完成后再继续依赖访问。

   问题：

   • 依赖处理器与系统配置支持；
   • 插入过多会显著破坏指令级并行性与性能。

2. 在条件分支附近插入阻止推测执行的处理

   通过编译器或程序改写，在关键分支及目标位置限制瞬态执行泄露。

   问题：

   • 需要识别所有危险代码位置；
   • 对热点代码的性能影响较大。

3. 微代码与处理器修复

   对分支预测或推测加载行为增加控制能力。

   问题：

   • 修复范围受具体微架构限制；
   • 防御越保守，性能代价通常越明显；
   • 新变种仍可能绕过既有策略。

Spectre 的困难在于它利用的是处理器广泛依赖的预测执行机制。完全关闭或大幅限制推测执行，会直接牺牲长期积累的性能收益。

攻击所面临的现实约束#

真实攻击环境中会出现许多噪声和限制：

• 受害程序的运行窗口很短；
• 系统并发访问会扰动 Cache 状态；
• 硬件预取可能干扰探测结果；
• 补丁与操作系统实现会改变攻击成功率。

因此，后续攻击研究往往追求三个指标：

TEE 与新的执行环境#

某些商用 TEE（Trusted Execution Environment） 在 Cache 侧信道面前并不天然安全。原因仍然是：

• 不同安全域可能共享底层 Cache；
• 软件或权限上的隔离并未等价为缓存资源隔离。

课堂还将这一问题延伸到现代执行场景，例如：

• 云服务与多租户环境；
• serverless 等共享基础设施；
• AI inference 等对性能高度敏感、资源复用密集的场景。

这些场景下，性能优化越积极，共享资源越多，越需要关注微架构侧信道。

不同硬件平台的攻击分布#

• Intel、AMD、ARM 等主流商用平台都存在不同类型的缓存侧信道风险；
• 一部分攻击利用 Cache 共享、命中时延等通用性质，因此跨平台；
• 一部分新型攻击依赖具体的查找逻辑、替换策略、目录、一致性协议、预取机制或瞬态执行，因此平台相关性更强；
• 现有商用处理器仍难以对所有 Cache 侧信道攻击提供完全防护。

商用处理器缓解方式#

Intel 与 ARM 面向已披露瞬态执行漏洞的部分缓解方式：

总体结论是：

• 商用处理器已经针对 Meltdown / Spectre 等公开漏洞部署了一系列缓解方案；
• 这些方案通常具有针对性，未必覆盖全部 Cache 侧信道变种；
• 安全增强会带来不同程度的性能开销。

基于软件的防御#

软件防御可以从三个层次展开。

基于硬件的防御#

缓存分组 / 分区方法#

核心思想是：

把 Cache 的不同区域分配给不同安全域，减少攻击者与受害者共享同一缓存位置的机会。

例如按 way 划分：

1
Way 0  Way 1        Way 2  Way 3
2
└── 受保护进程 ──┘  └── 其他进程 ──┘

优点：

• 从共享资源的根源上削弱侧信道；
• 隔离逻辑直观，安全语义清晰。

缺点：

• 可用缓存容量被切分，命中率可能下降；
• 硬件实现和资源管理复杂；
• 性能损失可能较明显。

缓存随机化方法#

传统 Cache 映射具有固定关系：

1
address → index → cache set

只要攻击者掌握映射规则，就可以构造与受害者冲突或用于探测的地址。
缓存随机化的目标是：

消除特定地址与缓存位置之间对攻击者稳定可预测的固定映射。

两类实现思路：

1. 基于表的随机映射

   • 把随机映射关系保存在表中；
   • 每次通过查表获得实际 cache index。

   特点：

   • 映射灵活；
   • 需要额外表存储与查找开销。

2. 基于计算的随机映射

   • 对地址进行加密或哈希式计算；
   • 根据计算结果确定实际映射位置。

   特点：

   • 附加存储较少；
   • 可以用较小开销实现随机化；
   • 仍不能从原理上完全消除所有侧信道。

结论是：

• 随机化通常具有较小的性能开销；
• 对多类缓存探测攻击有明显缓解效果；
• 但它主要提升攻击难度，并不能保证绝对安全；
• 商用处理器在采用强防护时仍会谨慎评估性能损失。

软件硬件协同#

除了分区和随机化，slides 还给出了两类继续发展的方向。