文章目录
- [1. 引言](#1. 引言)
-
- [1.1 背景：微架构攻击在云环境中尤其令人担忧](#1.1 背景：微架构攻击在云环境中尤其令人担忧)
- [1.2 论文的防御思路](#1.2 论文的防御思路)
- [1.3 四个核心挑战](#1.3 四个核心挑战)
- [1.4 解决方案------PDM框架（概览）](#1.4 解决方案——PDM框架（概览）)
- [1.5 主要贡献](#1.5 主要贡献)
- [1.6 实验结果](#1.6 实验结果)
- [2. 预备知识](#2. 预备知识)
- [3. 研究方法](#3. 研究方法)
-
- [3.1 探测](#3.1 探测)
-
- 方案1：Access+Reload（用于检测驱逐型攻击）
- [方案 2：Flush+Reload（检测瞬态执行攻击）](#方案 2：Flush+Reload（检测瞬态执行攻击）)
- [方案 3：方案 1 + 方案 2（同时检测两类攻击）](#方案 3：方案 1 + 方案 2（同时检测两类攻击）)
- [3.2 检测](#3.2 检测)
- [3.3 缓解](#3.3 缓解)
- [4. 评估](#4. 评估)
- [5. 相关工作](#5. 相关工作)
-
- [5.1 基于 HPC 的检测（主流，但租户用不了）](#5.1 基于 HPC 的检测（主流，但租户用不了）)
- [5.2 其他基于探测的检测（思路接近，但场景不同）](#5.2 其他基于探测的检测（思路接近，但场景不同）)
- [5.3 缓解方案（前人很多，但租户用不了或开销大）](#5.3 缓解方案（前人很多，但租户用不了或开销大）)
- [6. 限制和讨论](#6. 限制和讨论)
-
- [6.1 其他微架构攻击（覆盖范围的局限性）](#6.1 其他微架构攻击（覆盖范围的局限性）)
- [6.2 慢速逃避攻击](#6.2 慢速逃避攻击)
- [6.3 Spectre 的逃避](#6.3 Spectre 的逃避)
- [6.4 内存加密的掩码保护](#6.4 内存加密的掩码保护)
- [6.5 秘密标注](#6.5 秘密标注)
- [7. 总结](#7. 总结)
论文《PROBE+DETECT+MITIGATE (PDM): Enabling Cloud Tenants to Self-Defend against Microarchitectural Attacks》
1. 引言
1.1 背景：微架构攻击在云环境中尤其令人担忧
微架构攻击利用共享 CPU 缓存和不安全的硬件优化来窃取信息，在多租户公有云环境中尤其危险，因为不同租户可能共享同一台物理主机。
你和几十个不认识的人共用同一台物理机的 CPU、缓存、内存
只要有人在这台服务器上运行恶意代码，就能偷走你的隐私数据
虽然云安全是 "共享责任模型"（租户负责自己的数据安全，厂商负责基础设施安全），但在微架构攻击面前，云租户往往是束手无策的。
因为现有检测方案大多需要访问硬件性能计数器（HPC）或宿主机进程信息，而这些租户根本拿不到。另一方面，服务商可能因为性能开销大、补丁滞后等原因，迟迟不部署防御。
对比之前学的 Aegis
Aegis 看起来很美好，但它有一个致命的前提：防御者能在虚拟机内部读取 HPC 的值。
但在真实的 AWS 共享实例上，这个前提根本不成立
原文还指出：
像 PRIME+PROBE 和 Spectre 这些攻击，明明有补丁，但依然活跃。说明光靠服务商不够。
因此，有必要让云租户具备抵御微架构攻击的能力。这可以
（i）提高租户对微架构攻击的认知，进一步吸引公众关注这一活跃威胁；
（ii）迫使供应商和服务商更及时地开发并部署供应商补丁；
（iii）提供额外的防护层，与现有的服务商及检测和缓解方案协同工作。
1.2 论文的防御思路
核心思路分为两点：
第一，租户可以用和攻击者一样的探测技术来检测攻击。比如 FLUSH+RELOAD 攻击能用来偷数据，反过来也能用来检测有没有人在偷你的数据。
第二，我们可以只在检测到攻击的时候才触发防御，这样就能把性能开销降到最低。
这样一来，你不需要任何特殊权限，只需要能执行普通的用户态指令，就能检测到所有主流的微架构攻击。
1.3 四个核心挑战
要实现这个想法，我们需要解决四个关键挑战：
第一，很多微架构攻击不涉及缓存驱逐，比如 Spectre；
第二，你不能修改用户的程序代码，也不能全局插桩（修改源码不现实，二进制插桩开销大）
第三，要能处理云环境里各种各样的噪声
第四，要平衡检测精度、延迟和开销。
1.4 解决方案------PDM框架（概览）
为应对这些挑战，我们推出了PDM，这是一种供云租户在无需云服务商协助的情况下抵御微架构攻击的解决方案 。
（Probe+Detect+Mitigate）框架
- 一系列探测方案，使云租户能够独立检测各种微架构攻击。
- PDM 作为线程注入到受害者进程里，不需要修改源码
- 选择性触发防御：平时不开，检测到攻击才开
1.5 主要贡献
- 真正的租户级防御
不依赖服务商提供任何特殊资源（HPC、宿主机权限），租户自己就能部署。
- 解决了上述四个挑战
（i）覆盖各类微架构攻击
（ii）无需修改源代码或进行二进制插桩
（iii）处理来自多种来源的噪声
（iv）在性能开销与准确性之间取得平衡。
- 在真实云环境中验证了方案的有效性
1.6 实验结果
2. 预备知识
2.1 微架构攻击
缓存侧信道攻击
攻击者通过测量内存访问延迟，判断目标缓存行是否被受害者加载进缓存，从而推断受害者的内存访问模式，进而恢复密钥等敏感信息。
典型攻击包括：FLUSH+RELOAD、FLUSH+FLUSH、EVICT+RELOAD、PRIME+PROBE 及其变种、RELOAD+REFRESH 等
禁用内存共享可以防 FLUSH+RELOAD等攻击（因为它们需要共享内存）；
但对 PRIME+PROBE 无效（不需要共享内存），随机化缓存或缓存分区可以防御，但需要改硬件或牺牲性能。
关键观察（PDM 探测的基础）
所有缓存侧信道攻击，都会把受害者的数据从缓存里踢出去。这会导致受害者下一次访问这个地址时，出现异常的缓存缺失
瞬态执行攻击
这类攻击利用现代 CPU 的乱序执行和推测执行优化（如Spectre 攻击）。当 CPU 发生预测错误时，会回滚所有架构状态，但微架构状态（比如缓存）不会被回滚。攻击者可以利用这个残留的微架构状态窃取数据。
关键观察（PDM 探测的另一个基础）
所有瞬态执行攻击，都会把受害者的数据偷偷拉进缓存里。这会导致受害者下一次访问这个地址时，出现异常的缓存命中（cache hit）
2.2 威胁模型
作者采用文献中标准的微架构攻击威胁模型：
攻击者是与受害者同驻在同一物理主机上的普通云租户。攻击者只能在自己的云实例中执行非特权代码，没有特权指令或提升权限。云提供商已禁用租户对主机或硬件级信息（包括 HPC）的直接访问。
租户信任服务商，但也意识到服务商可能无法及时跟进所有新型攻击或不愿部署所有防御（因性能开销）。
只考虑真实云环境（有噪声），数据泄露速率相对较低（如 Spectre-PHT 只有 41B/s，跨 VM 的攻击需要数秒或数分钟）
通俗解释：
攻击者是谁：
就是云上另一个坏租户，和你开在同一台物理机上的虚拟机或容器。
攻击者有什么能力：
能执行普通代码，能读自己的内存，能测量时间。
攻击者没有的能力：
不能读 HPC（服务商禁了），不能改内核，不能提权。
环境特点：
云环境不是寂静的实验室，有很多正常负载造成的"噪音"（缓存争用、调度延迟）。但好消息是，数据泄露速率也不高（比如 Spectre 一秒只能偷 41 字节），所以防御方有时间反应。
PDM 的安全覆盖范围
PDM 能检测和防御那些影响受害者缓存占用状态的攻击（即攻击会改变受害者数据在缓存中的分布）。
其次，PDM 能够检测但无法缓解（仅部分覆盖）那些将 Spectre 用于直接数据泄露和内存拒绝服务之外目的的攻击，因为这些攻击针对的是完整性或可用性而非机密性。
最后，那些不改变受害者缓存占用状态的攻击不在覆盖范围内（未被覆盖）。
为了更全面地了解这类攻击的覆盖范围，作者分析了过去十年在主流安全顶会上发表的169篇微架构攻击相关论文。研究发现，28%的论文针对幽灵漏洞，37%针对基于缓存的侧信道攻击。
这表明，尽管PDM仅能访问租户级别的资源，但其仍覆盖了大部分常见攻击类型。
3. 研究方法
概述：
PDM 由三个主要组件组成：探测、检测和缓解。
首先，探测组件监控受害者的内存空间，捕获异常的缓存命中或缺失作为检测特征。
其次，检测组件包括三个子模块：注入模块将 PDM 作为线程注入受害者进程；检测引擎使用两级分类器处理特征；噪声处理模块过滤来自受害者和同驻租户的噪声。
最后，缓解组件在检测到攻击时，通过缓存混淆或内存加密阻止数据泄露。
一句话概括：
用攻击者的技术探测自己的内存→用机器学习判断有没有人在攻击→只有真的被攻击了才启动防御
和之前学的 Aegis 最本质的区别：
Aegis：持续注入噪声，不管有没有攻击都有开销
PDM：检测到攻击才启动防御，平时几乎零开销
3.1 探测
本节设计了一系列探测方案，用于监控目标的内存空间并收集数据以进行检测（通过主动访问内存，感知攻击者留下的"痕迹"）。
方案1：Access+Reload（用于检测驱逐型攻击）
适用对象：
FLUSH+RELOAD、PRIME+PROBE 等会把受害者数据踢出缓存的攻击。
检测微架构攻击的一个直接方法是关注攻击者驱逐操作导致的异常缓存缺失。当攻击者驱逐、刷新或填充受害者的数据时，我们可以通过探测相同的内存地址来检测攻击，因为访问会由于缓存缺失而变慢。
Access：我先访问一下自己的秘密数据，把它加载到缓存里
Wait：等一小段时间（比如 0.3ms），这段时间就是 "攻击窗口"
Reload：我再访问一次这个地址，测一下时间
判断：如果时间很长（超过缓存命中阈值），说明有人在 Wait 阶段把我的数据踢出了缓存→可能有攻击
为什么这个方案有效？
所有缓存侧信道攻击的第一步都是清空受害者的缓存。只要在攻击窗口内发生了清空操作，受害者第二次访问就会变慢。这个方案就是专门抓这个 "清空" 动作的。
方案 2：Flush+Reload（检测瞬态执行攻击）
适用对象：
Spectre 等推测执行攻击（攻击者不会踢出你的数据，反而会把你的数据带进缓存）
方案 1 只能监控缓存缺失，无法检测依赖推测内存访问而不是驱逐的瞬态执行攻击
为了解决这个问题，我们借用了 FLUSH+RELOAD 攻击的探测技术：先刷新内存，然后访问它，任何在等待窗口内发生的投机内存访问都会被检测为异常缓存命中。
具体做法：
FLUSH+RELOAD 攻击能用来偷数据，反过来也能用来检测有没有人在偷你的数据
Flush：先用 clflush 把目标地址从缓存中清空
Wait：等待
Reload：再读该地址，测量时间
如果 Reload 很快（cache hit）→ 说明在等待期间，有人（攻击者）通过推测执行把你的数据加载进了缓存 → 可能遭受 Spectre 攻击
方案 3：方案 1 + 方案 2（同时检测两类攻击）
由于方案 1 和方案 2 都只能检测一部分攻击，方案 3 自然地将这两个基本方案结合起来。
具体来说，它对每个地址交替执行方案 1 和方案 2。这样既能抓驱逐攻击，也能抓瞬态执行攻击。
方案 3+：多路复用方案 3（扩大探测范围）
在等待间隔内，不闲着，而是对多个地址依次执行第一次操作（Access 或 Flush），然后再依次执行 Reload。这样一次等待窗口可以覆盖最多 512 KiB 的内存范围，提高探测效率。
3.2 检测
本节详细介绍 PDM 如何将自身注入受害者进程以检测攻击，同时处理噪声。
把探测到的原始数据（快/慢、命中/未命中）转换成特征，用机器学习判断是否真的被攻击，同时处理好噪声。
注入
PDM 的注入分两步：
地址提取和代码注入。地址提取离线执行，用于定位秘密依赖的内存访问指令和秘密本身。代码注入将 PDM 作为线程加载到受害者进程中，不需要修改源码或二进制。
第一步：地址提取（离线只做一次）
先找到你的程序里哪些内存地址存了敏感数据
方法：
用现有的自动化缓存侧信道漏洞扫描工具（比如 Microwalk、CacheQL）扫描二进制文件
结果：
得到一个敏感地址列表，这就是 PDM 的探测范围
优点：
离线执行，不影响运行时性能；支持没有源码的二进制文件
第二步：代码注入（运行时执行）
将 PDM 编译成共享库
原文明确说了不用动态二进制插桩（DBI），因为 DBI 开销太大。PDM 用了两种更轻量的方式：
启动时注入 ：用LD_PRELOAD环境变量，在程序启动时自动加载 PDM 共享库
运行时注入：用ptrace系统调用，把 PDM 共享库注入到已经在运行的进程里
注入后，PDM 会作为一个独立的线程运行，和受害者共享同一个地址空间，能直接访问所有敏感内存。而且这个线程被绑定到和受害者同一个 CPU 核心上，保证能准确探测到缓存状态变化。
检测引擎
PDM 检测引擎将 探测模块输出的数据 组织为多元时间序列，并使用推理开关触发两级检测过程，以平衡精度、开销和前置时间。
核心设计：
多元时间序列特征
探测模块输出的数据（比如 Access+Reload 的命中/未命中比例、Flush+Reload 的命中比例）被组织成时间序列。
这些特征经过移动平均、移动标准差、归一化后，输入一个轻量级 Transformer 分类器
推理开关
虽然我们的分类器很轻量，但持续执行 ML 推理仍然会引入不必要的开销。因此我们引入了推理开关，只有当秘密被访问或驱逐时才触发 ML 推理。
如果一直跑机器学习，CPU 开销会很大。
所以加了开关：只有当探测数据出现异常时（比如 Access+Reload 出现了慢读，或者 Flush+Reload 出现了快读），才触发 ML 推理。
否则开关关闭，不做 ML。
两阶段检测（平衡速度和精度）
快速模型（fast classifier）：调参目标是低漏报（尽量不错过攻击）。一旦它报警，立即触发缓解。
慢速模型（slow classifier）：调参目标是低误报（确认是不是真攻击）。如果它确认是误报，就撤销缓解；如果确认是真攻击，就保持缓解，并通知租户/服务商迁移或进一步处理。
这样既保证了低延迟（快速模型很快响应），又避免了长期误报（慢速模型可以修正）。
流程：快模型先报警→立即启动轻量级防御→慢模型在后台验证→如果是假阳性就关防御，如果是真攻击就升级防御
噪声处理
租户级解决方案自然会受到各种背景噪声的影响，包括来自受害者应用本身的噪声和来自同驻租户的噪声，这会导致检测出现大量假阳性。
受害者噪声（自己的正常访问）
问题：受害者自己正常访问敏感数据也会导致缓存命中 / 缺失，会被误判为攻击
解决：
用另一个线程监控受害者是否正在主动访问这些地址。如果是，就调整探测窗口，避免误判。
同驻噪声（其他租户的噪声）
问题：其他租户的缓存密集型应用会把整个 L3 缓存占满，导致受害者的缓存缺失率上升
解决：专门开一个线程监控整个 L3 缓存的整体负载。PDM 收集 L3 整体负载作为额外特征，动态调整探测的等待间隔
3.3 缓解
PDM 通过仅在检测到攻击时触发缓解措施来实现高效的攻击缓解。它利用了几种用户空间缓解方法，包括混淆（用于缓存侧信道攻击）、内存加密（用于瞬态执行攻击）和迁移（用于确认的攻击）。
这是 PDM 开销极低的核心原因：
平时完全不做防御，只有检测到攻击才启动。而且所有缓解措施都是非破坏性的，即使是假阳性也不会影响应用的正常运行。
缓存侧信道攻击的缓解：混淆
存侧信道攻击旨在推断受害者的内存访问模式，一个众所周知的缓解方法是混淆这些模式以增加攻击者观察到的噪声。PDM 采用两级混淆方法。
第一级
PDM 自己的探测操作（Access/Flush/Reload）本身就会扰乱缓存状态，增加攻击者的噪声。
第二级
对受攻击的内存页进行主动预取（prefetch），不断把数据拉回缓存，让攻击者看到一片混乱，无法分辨真实访问模式。
这个防御不仅没有开销，反而会提高应用的性能------ 因为预取会减少应用自己的缓存缺失。
瞬态执行攻击的缓解：内存加密
原理：把敏感数据在内存中加密存储（用 XOR 掩码），只有在合法访问时才解密。
实现方法（概述）：
- 把包含秘密的内存页标记为 PROT_NONE（禁止访问）
- 当受害者正常访问时，会触发 SIGSEGV 信号 ，信号处理器构建一个"跳板"（trampoline）：
计算真实访问地址
读取加密数据 → 解密 → 放入寄存器
执行原指令
跳回原程序
3.当攻击者推测执行时，CPU 不会在猜测阶段触发信号，因此拿不到解密后的明文，只能拿到密文 → 攻击失败。
确认攻击后的进一步行动：
一旦慢模型确认了检测到的攻击，租户可以采取更激进的缓解措施，比如迁移工作负载并通知云提供商。
如果真的被持续攻击，PDM 会报警，用户可以用用户态 checkpoint/restore 工具（比如 CRIU）把容器迁移到其他物理主机上，彻底摆脱攻击者。
4. 评估
核心结论：
PDM 在完全不需要任何云厂商支持、没有 HPC 访问权限的情况下，实现了：
极高的检测精度 ：本地 TPR≥99.72%，FPR≤0.13%；AWS Fargate TPR≥98.63%，FPR≤0.83%
极低的性能开销 ：SPEC CPU 2017 平均 2.47%，无攻击时几乎为 0
完美的缓解效果 ：完全阻断所有主流缓存攻击和 Spectre 变种
极强的鲁棒性：能有效处理云环境中的各种噪声，对抗规避攻击的能力远优于现有方案
5. 相关工作
前人做了什么，PDM 和他们有什么不同
论文把所有现有微架构攻击防御方案分成了两大类，逐一指出它们的致命缺陷，从而凸显 PDM 的独特性。
5.1 基于 HPC 的检测（主流，但租户用不了）
CacheShield：受害者自己监控 HPC 来检测攻击。效果不错，但需要 HPC 访问权限。
Cho et al.：监控整个系统的 HPC 来找到攻击者进程。同样需要 HPC。
其他类似工作：基本都依赖 HPC 或宿主机的全局视图。
PDM 的不同：
完全不依赖 HPC，只用租户自己能访问的资源（自己的内存、自己的 CPU 时间）。
5.2 其他基于探测的检测（思路接近，但场景不同）
有工作针对 SGX enclave 做类似的探测，但他们需要 HPC 或页表访问权限，云租户拿不到。
WaitGuard：监控特定缓存行来检测 flush 攻击，但依赖特定 CPU 型号。
PDM 的不同：
不依赖任何硬件特性或特权，纯用户态，且覆盖更广（包括 Spectre）。
5.3 缓解方案（前人很多，但租户用不了或开销大）
常量时间代码、内存 fences、标记页为不可缓存：要么需要改代码，要么需要内核模块，要么性能开销大。
Cipherfix：对敏感数据持续加密，但始终有开销（哪怕没攻击）。
PDM 的不同：
只在检测到攻击时才触发缓解（混淆/加密），无攻击时几乎零开销。而且所有缓解都在用户态完成，不依赖宿主机
一句话总结
前人工作要么需要 HPC/宿主机特权（租户拿不到），要么一直开着重防御（开销大）。PDM 是第一个纯租户级、按需触发、能同时对付缓存攻击和 Spectre 的自防御方案。
6. 限制和讨论
作者指出 PDM 目前还不能覆盖所有情况，以及未来可以改进的方向。
6.1 其他微架构攻击（覆盖范围的局限性）
PDM 专注于那些通过主动内存探测改变受害者缓存占用状态的攻击。对于不改变缓存状态的攻击，PDM 目前无法覆盖。
如果要覆盖，可以扩展探测思路
例如，针对端口竞争，可以部署一个并发线程去探测 CPU 端口的延迟变化，同样可以用"探测"的思路来检测。这展示了用攻击的侧信道技术反过来做防御的思想可以推广。
6.2 慢速逃避攻击
攻击者可以故意放慢攻击速度来躲避检测。
放慢攻击速度，试图让自己的行为淹没在正常的系统噪声中。
虽然理论上存在这种攻击，但在真实云环境中几乎没有实用价值（耗时太长），但依然可以通过增加一个专门的 "慢速模式" 探测线程来解决。
6.3 Spectre 的逃避
PDM 检测 Spectre 的依据是推测执行导致的意外缓存命中。
要完全逃避检测，攻击者必须消除推测执行对缓存的影响，但这极具挑战性。
6.4 内存加密的掩码保护
一个合理的担忧：内存加密的XOR 掩码本身也可能成为攻击目标。
PDM 的设计：
每次写操作都会用 AES 伪随机数生成器（PRNG）刷新掩码，所以掩码的有效窗口很短。
此外，可以把掩码也加入 PDM 的探测范围，监控是否有异常访问。
也可以让掩码依赖于一个很长的秘密，使得攻击者必须泄露整个秘密才能推导出掩码。
6.5 秘密标注
PDM 需要提前知道哪些内存地址包含秘密（以确定探测范围）。这通常需要开发者手动标注，或使用半自动化工具。
7. 总结
PDM 使云租户无需依赖服务商资源即可自主检测和缓解缓存侧信道攻击与瞬态执行攻击：
（i）通过探测监控受害者的内存空间；
（ii）以线程形式注入自身以检测攻击并处理干扰；
（iii）在检测到攻击后缓解数据泄露问题。
并通过实验证明了其有效性、高效性和鲁棒性，从而提升租户安全意识、推动服务商改进并作为现有防御的补充层。