Oakland’25：论文的重点研究内容
这篇论文的题目为：SoK: Integrity, Attestation, and Auditing of Program Execution。
解决了运行时完整性研究中的哪些问题？
[Q1] CFA 和 CFI 的目标有何不同？
[Q2] CFI 与 CFA 的假设、特性和设计空间分别是什么？它们有哪些相似点和不同点？
[Q3] CFA 与远程证明对 CFI 策略的遵循有何不同？CFA 是否能够发现 CFI 无法检测到的攻击（反之亦然）？
[Q4] CFI 和 CFA 是否能够在同一平台上共存？
[Q1] How do CFA and CFI goals differ?
[Q2] What are the assumptions, features, and design spaces of CFI vs. CFA, as well as their similarities and differences?
[Q3] What makes CFA different from remotely attesting adherence to a CFI policy? Could CFA uncover attacks that CFI would not (and vice-versa)?
[Q4] Could CFI and CFA coexist on the same platform?
这篇论文重点关注哪些运行时完整性技术？
- 由于现有的 CFA 方案数量较少且可管理，作者旨在收录所有相关文献（除非存在无意的疏漏）。
- 鉴于 CFI 方案的数量众多，作者采用以下标准筛选过去 10 年内的研究成果：
- 发表在知名安全会议（如 USENIX Security、IEEE S&P、CCS 和 NDSS）上的论文。
- 被引用次数超过 100 的论文，表明其在后续研究中的广泛影响。
- 被主流编译器或硬件架构采用的论文或方案。
- We aim to include all available literature on CFA due to the manageable number of existing proposals (except unintended oversights).
- Given the extensive volume of CFI proposals, we use the following criteria for selection within the past 10 years:
- Papers published in prestigious security-focused conferences such as USENIX Security, IEEE S&P, CCS, and NDSS.
- Papers with more than 100 citations, indicating their broad influence in subsequent work.
- Papers or proposals adopted in mainstream compilers or hardware architectures.
这篇论文的主要贡献是什么？
在本文中，作者通过系统性分析 CFI 和 CFA 的基本目标及其权衡关系，探讨二者之间的关联与区别：
- 为此，作者首先对现有的运行时防御机制进行系统性回顾，以提供研究背景，并将 CFI 和 CFA 置于更广义的执行完整性防御体系中。
- 随后，作者根据设计选择对近年来的 CFI 和 CFA 研究进行分类，权衡其优缺点，以更全面地理解现有方案的局限性。
- 最后，作者讨论 CFI 与 CFA 之间的未解关联，并探讨未来的研究方向。
- Towards this goal, we present a systematic review of existing runtime defenses to provide context and position CFI and CFA within the broader landscape of execution integrity defenses.
- Subsequently, we classify recent work in CFI and CFA according to design choices, weighing their advantages and disadvantages and aiming to grasp a better understanding of existing limitations.
- Finally, we discuss missing links between CFI and CFA and future research avenues.
本篇文档重点关注什么内容？
考虑到我们的主题是寻找体系结构安全与内存安全机制相关的话题，本篇文档的重点将侧重于以下几个方面：
- 这篇论文提到、介绍并分析了哪些已经实际部署的CFI和CFA安全机制；
- 这些CFI安全机制是否已经能够被体系结构侧信道攻击所绕过（与先前2024/11/18的博客所对应）；
- 在前两者的基础上思考体系结构安全与内存安全之间的关系。
Oakland’25：运行时防护有哪些
内存破坏漏洞的攻击步骤与安全防护的对应关系：
| # | 攻击步骤 | 安全防护 |
|---|---|---|
| 1 | Memory Vulnerability | |
| 2 | Integrity Violation | Software Compartmentalization |
| 3 | Exploit Payload | Software Diversification |
| 4 | Exploit Dispatch | Data Integrity（建立在W^X基础上） |
| 5 | Exploit Execution | Runtime Attestation（建立在可信根基础上） |
内存破坏漏洞的攻击步骤：
- Memory Vulnerability：在所有运行时攻击中，发现并利用内存破坏漏洞是必不可少的前提条件。对内存地址的非法访问（无论是读取、写入，还是两者兼有）取决于具体的漏洞类型。需要注意的是，仅允许只读访问的漏洞本身不足以破坏目标程序的执行完整性。
- Integrity Violation：利用具备非法写入权限的漏洞，使攻击者能够篡改程序的多个方面，包括 (i) 程序代码（存储在内存中的指令）、(ii) 控制数据（如返回地址和函数指针）以及 (iii) 非控制数据（如数据变量和指针）。
- Exploit Payload：如果先前的防御机制被绕过，攻击者可以注入载荷以操控目标程序的数据流和控制流。通常，载荷注入过程需要对程序的内存布局有一定的了解。
- Exploit Dispatch：为了成功发起复杂的攻击，攻击者需要引导目标程序执行注入的载荷。这一步对于 ROP 等高级代码重用攻击至关重要，其中，攻击者通过操控栈指针，使程序按照预定顺序执行一系列精心挑选的 gadget。每个 gadget 在执行完毕后都会返回到下一个 gadget 的特定内存地址，从而实现预期的攻击行为。
运行时防护：
- Software Compartmentalization：隔离与分区机制在强制执行访问控制权限方面发挥关键作用，以减轻完整性破坏的风险。这些机制限制了攻击者可访问的目标，通常能够在攻击的早期阶段加以阻断，或防止其向系统的其他部分扩散。例如，访问控制机制 AArch64 的 (Un)Privileged Execution Never 特性显著提高了直接篡改程序代码的难度。代码指针完整性（Code Pointer Integrity, CPI）是一种安全机制，通过将所有代码指针及指向代码的数据指针存储在隔离的内存区域中，以防止其被篡改。
- Software Diversification：对此，软件多样化通过引入随机化来增加不确定性，旨在阻碍可重用漏洞利用的构造。例如，地址空间布局随机化（Address Space Layout Randomization, ASLR）和指令集随机化（Instruction Set Randomization, ISR）是两种轻量级防御机制，通过对内存布局进行随机化，使得载荷注入在控制流劫持和代码注入攻击中的实施变得更加困难。
- Data Integrity：控制流完整性（Control Flow Integrity, CFI）和数据流完整性（Data Flow Integrity, DFI）是两种常见的防御机制，旨在检测并阻止此阶段的控制流劫持攻击和仅数据攻击。这些技术通过制定并强制执行程序执行过程中必须遵循的策略来实现防护。
- Runtime Attestation：因此，运行时认证机制被提出作为最后一道防线，以便以可信的方式远程验证代码和执行完整性。这些机制旨在检测代码篡改或控制流/数据流的违规行为。此外，它们还提供了在操作过程中向远程方证明目标程序执行完整性的方法，并在某些情况下，在发生漏洞利用时，能够审计根本原因漏洞。
Oakland’25：现有的CFI和CFA机制
Oakland’25：体系结构侧信道攻击向量
微架构攻击的出现可能会影响 CFI 和 CFA。尽管这些防御主要针对内存破坏攻击，但某些 Spectre 变体同样可能对它们产生影响。例如，Spectre v1 利用数组访问前边界检查后的错误推测，而 Spectre v2 则利用间接调用或跳转目标的错误预测。两者均采用 Flush+Reload 隐蔽信道来泄漏数据。研究表明，即使在启用了所有默认缓解措施的情况下，类似 Spectre v1 的攻击仍能绕过基于软件的 CFI 防御（如 LLVM-CFI）。虽然已经提出了诸如 SPECCFI 和 MicroCFI 等专门的缓解措施，但 Spectre v2 的威胁依然严重，且尚未得到完全解决。
The emergence of microarchitectural attacks can affect CFI and CFA. While these defenses focus on memory corruption attacks, certain variants of Spectre [160] can affect them. For instance, Spectre v1 exploits misspeculation following a bounds-check prior to an array access, while Spectre v2 exploits misprediction of the target of an indirect call or jump. Both utilize a Flush+Reload channel [161] to leak data. Research has demonstrated that Spectre v1-like attacks can bypass software-based CFI defenses, such as LLVM-CFI [18], even in the presence of all default mitigations [162]. While specialized mitigations, such as SPECCFI [163] and MicroCFI [164], were proposed, Spectre v2 remains severe and yet to be fully mitigated.
尽管现代的 CFI 防御（例如 Intel CET）已经考虑了 Spectre 威胁模型，并设计时内置了对 Spectre v2 的防护，但近期的攻击（如InSpectre Gadget）揭示了新的可利用 gadget 类型，即使在 CET 的间接分支跟踪（IBT）功能或其最近的细粒度对应机制 FineIBT 启用的情况下，也能成功发起 Spectre v2 攻击。PACMAN 则是另一种近期攻击，其利用推测性执行和内存破坏绕过了 Apple M1 SoCs 上的 ARM 指针认证。
Although contemporary CFI defenses, such as Intel CET [21], consider a post-Spectre threat model and are designed with built-in protection against Spectre v2 [165], recent attacks, such as InSpectre Gadget [166], have uncovered new types of exploitable gadgets that can successfully mount Spectre v2 attacks, even if the CET’s Indirect Branch Tracking (IBT) feature or its recent fine-grained counterpart, FineIBT [22], are active. PACMAN [30] stands out as another recent attack that exploits speculative execution along with memory corruption to bypass ARM Pointer Authentication on Apple M1 SoCs.
与 CFI 类似，利用受到侧信道攻击影响的架构组件的 CFA 同样可能面临脆弱性。另一方面，一些与秘密依赖相关的时间侧信道攻击（这些攻击利用软件实现漏洞而非微架构漏洞）依赖于目标程序控制流路径的差异，为基于 $CF_{Log}$ 分析的漏洞利用识别提供了机会。
Similar to CFI, CFA leveraging architectural components vulnerable to side channels could be equally vulnerable. On the other hand, several secret dependency-related time side channels [167] (that exploit software implementation bugs, rather than micro-architectural bugs) depend on differences in the target program’s control flow path, opening opportunities for exploit identification based on $CF_{Log}$ analysis. To our knowledge, the latter remains unexplored in prior work.
参考文献
[1] Ammar, M., Caulfield, A., & Nunes, I. D. O. (2025). Sok: Integrity, attestation, and auditing of program execution. In 2025 IEEE Symposium on Security and Privacy (SP). IEEE Computer Society.