C++ 控制流完整性（CFI）：在 C++ 编译器加固中通过间接跳转表校验防御高级内存劫持攻击

C++ 控制流完整性（CFI）：在 C++ 编译器加固中通过间接跳转表校验防御高级内存劫持攻击

I. 引言：C++与现代安全挑战

C++ 作为一种高性能、灵活的编程语言，在操作系统、嵌入式系统、游戏引擎、高性能计算等领域占据核心地位。然而，其对内存的直接操作能力，虽然赋予了开发者强大的控制力，也带来了固有的安全风险。内存安全漏洞，如缓冲区溢出、释放后使用（Use-After-Free）、双重释放（Double Free）等，长期以来是C++程序被攻击的主要途径。

随着攻击技术的发展，传统的防御机制，如地址空间布局随机化（ASLR）和数据执行保护（DEP/NX），虽然提高了攻击的难度，但已无法完全抵御高级内存劫持攻击。ASLR通过随机化内存布局来对抗硬编码地址的攻击，但信息泄露漏洞可以绕过它。DEP/NX阻止在数据段执行代码，但攻击者可以通过重用程序现有代码（即“gadgets”）来构造恶意行为，这被称为面向返回编程（Return-Oriented Programming, ROP）或面向跳转编程（Jump-Oriented Programming, JOP）。这些攻击的核心在于劫持程序的控制流，使其执行攻击者预期的指令序列，而非程序设计的合法路径。

控制流劫持（Control Flow Hijacking）是现代软件安全面临的最大威胁之一。它允许攻击者完全改变程序的执行流程，从而导致数据泄露、权限提升甚至远程代码执行。为了有效对抗这类攻击，我们需要一种更根本的防御机制，能够确保程序始终沿着预期的、合法的路径执行。这正是控制流完整性（Control Flow Integrity, CFI）技术诞生的初衷。

II. 控制流完整性（CFI）概述

控制流完整性（CFI）是一种安全机制，旨在确保软件在运行时遵循预定义的、合法的控制流图（Control Flow Graph, CFG）。它的核心思想是：在程序执行的任何时刻，对所有的控制流转移（无论是直接跳转、间接跳转、函数调用还是函数返回）进行校验，确保目标地址是编译器或运行时系统预先确定为合法的。

CFI的哲学：
CFI将程序的所有可能执行路径建模为一张有向图——控制流图（CFG）。图中的节点是基本块（Basic Block），边是控制流转移。CFI的目标是，在程序运行时，任何实际发生的控制流转移都必须是CFG中存在的一条合法边。

CFI的分类：

1. 前向CFI (Forward-edge CFI)： 关注间接跳转和间接调用的目标地址校验。例如，函数指针调用、虚函数调用、switch语句的跳转表等。攻击者常常利用这些点来执行JOP或COP（Call-Oriented Programming）攻击。
2. 后向CFI (Backward-edge CFI)： 关注函数返回地址的校验。例如，函数从栈上返回时，校验返回地址是否被篡改。ROP攻击主要利用的就是函数返回地址被劫持。

本文将重点聚焦于前向CFI，特别是如何通过间接跳转表校验来防御高级内存劫持攻击。

CFI的实现粒度：

• 粗粒度CFI (Coarse-grained CFI)： 对合法目标地址的限制相对宽松。例如，允许任何间接调用跳转到任何已知函数入口点。这种CFI的性能开销较低，但可能无法阻止攻击者在合法的函数入口之间跳转，从而实现细粒度的控制流劫持。
• 细粒度CFI (Fine-grained CFI)： 对合法目标地址的限制非常严格。例如，要求间接调用的目标函数不仅是一个合法的函数入口，而且其类型签名（参数数量、类型、返回类型、调用约定）必须与调用点预期的签名完全匹配。这种CFI能提供更强的保护，但性能开销和实现复杂度也更高。

CFI的挑战：
CFI并非没有代价。其主要挑战包括：

• 性能开销： 运行时插入的校验代码会增加程序的执行时间。
• 兼容性： 对现有代码库的修改、跨模块/库的CFI一致性问题。
• 完善性： 并非所有程序都能精确地构建完整的CFG，特别是对于存在动态代码生成（JIT）或反射机制的程序。

III. 间接跳转与调用：高级攻击的温床

C++中存在多种间接控制流转移点，它们是高级内存劫持攻击者青睐的目标。理解这些点的工作原理及其脆弱性，是设计有效防御机制的前提。

C++中的间接控制流转移点：

1. 虚函数调用 (Virtual function calls)： C++多态性的核心机制。通过对象的虚函数表指针（vptr）查找虚函数表（vtable），进而调用实际的函数。
2. 函数指针调用 (Function pointer calls)： 允许程序在运行时根据条件调用不同的函数。
3. switch 语句（跳转表）： 当switch语句包含大量case分支时，编译器通常会优化生成一个跳转表。根据表达式的值，程序会查表并间接跳转到相应的case分支代码。
4. longjmp / 异常处理： setjmp和longjmp提供了一种非局部的跳转机制。异常处理机制在底层也涉及控制流的复杂跳转。

攻击者如何利用这些点进行劫持：

• ROP (Return-Oriented Programming)： 攻击者通过栈溢出等手段篡改函数返回地址，使其指向程序中已有的小段代码（gadgets）。每个gadget执行少量操作后，通过ret指令返回到栈上下一个伪造的返回地址，从而形成一个gadget链，执行任意恶意逻辑。ROP主要针对后向控制流。
• JOP (Jump-Oriented Programming)： 类似于ROP，但攻击者篡改的是函数指针或虚函数表项，使其指向gadget，然后通过间接跳转或调用指令（如jmp [reg]、call [reg]）来执行gadget链。JOP主要针对前向控制流。
• COP (Call-Oriented Programming)： 与JOP类似，但更侧重于利用间接调用指令。

C++虚函数机制回顾及其劫持风险：

虚函数是C++实现多态的关键。每个包含虚函数的类都会有一个虚函数表（vtable），其中存储了该类及其基类所有虚函数的地址。每个该类的对象都会包含一个虚函数表指针（vptr），指向其对应类的vtable。

// 示例：虚函数机制
class Base {
public:
    virtual void foo() { /* ... */ }
    virtual void bar() { /* ... */ }
};

class Derived : public Base {
public:
    void foo() override { /* ... */ } // 覆盖Base::foo
    void baz() { /* ... */ }          // Derived特有方法
};

int main() {
    Base* ptr = new Derived();
    ptr->foo(); // 虚函数调用
    delete ptr;
    return 0;
}

在上述代码中，ptr->foo()的调用过程是：

1. 通过ptr获取Derived对象的vptr。
2. 通过vptr找到Derived类的vtable。
3. 在vtable中查找foo函数对应的地址。
4. 间接调用该地址上的函数（即Derived::foo）。

vtable 劫持攻击示例：
如果攻击者能够通过内存破坏漏洞（如缓冲区溢出）篡改一个对象的vptr，使其指向一个伪造的vtable，或者直接篡改vtable中的函数地址，那么当程序进行虚函数调用时，就会跳转到攻击者指定的地址执行恶意代码。

假设内存中有一个Base* ptr，其vptr指向一个合法的vtable_Derived。如果攻击者能将ptr所指向内存区域的vptr覆盖为指向一个伪造的fake_vtable，而fake_vtable的第一个条目（对应foo()函数）被设置为攻击者的payload地址，那么当ptr->foo()被调用时，程序就会执行攻击者的payload。

这种攻击方式非常强大，因为它允许攻击者在程序的关键执行路径上插入自己的逻辑，绕过DEP/NX。

IV. 基于间接跳转表校验的CFI机制

为了防御上述攻击，基于间接跳转表校验的CFI机制应运而生。其核心思想是：为程序中的每一个间接控制流转移点，在编译时或链接时，识别并记录所有合法的目标地址集合；在运行时，对每次间接转移的目标地址进行校验，确保其属于预定义的合法集合。

实现策略：

1. 编译时分析 (Compile-time Analysis):

   • 构建控制流图 (CFG)： 编译器或链接器会分析程序的源代码和二进制代码，构建一个尽可能完整的CFG。这包括识别所有的函数、基本块以及它们之间的控制流关系。
   • 识别间接控制流转移点： 找出所有的虚函数调用、函数指针调用、switch语句等。
   • 确定合法目标集合： 对于每个间接控制流转移点，编译器会确定其所有可能的合法目标地址。例如，对于一个虚函数调用，其合法目标是所有覆盖该虚函数的派生类实现。对于一个函数指针，其合法目标是所有类型签名匹配的函数。
   • 生成类型签名/标签： 为每个函数或每个间接调用点生成一个唯一的“类型签名”或“标签”，用于在运行时进行匹配校验。这些标签可以编码函数的返回类型、参数类型、调用约定等信息。

2. 运行时插桩 (Runtime Instrumentation):

   • 插入校验代码： 编译器在每个间接控制流转移点之前，插入额外的校验代码。
   • 执行校验： 这些校验代码在程序运行时执行，获取即将被调用的目标地址，并根据编译时生成的合法目标集合或标签进行匹配。
   • 违规处理： 如果目标地址不合法，CFI机制会立即终止程序，发出安全警报，防止攻击继续。

方法一：粗粒度CFI (e.g., Google’s CFI for Chromium)

粗粒度CFI的目标是确保间接跳转或调用只跳转到已知的函数入口点。它不对函数的类型签名进行严格匹配，只检查目标地址是否是程序中某个函数的合法入口。

• 思想： 所有函数指针或虚函数调用都必须跳转到程序中已知的、合法的函数入口地址。

• 实现：

  • 在编译时，编译器构建一个所有函数入口地址的列表或位图。
  • 在运行时，当发生间接调用时，校验目标地址是否在这个列表中。

• 代码示例（伪代码）：

  // 编译时：收集所有合法函数入口
  // 假设 g_valid_function_entries 是一个哈希集合或位图
  void compiler_phase_collect_entries(const std::vector<Function*>& functions) {
      for (Function* func : functions) {
          g_valid_function_entries.add(func->get_entry_address());
      }
  }
  
  // 运行时插桩：在每个间接调用点前插入
  void indirect_call(void (*func_ptr)()) {
      // 运行时检查：目标地址是否是合法的函数入口
      if (!g_valid_function_entries.contains(func_ptr)) {
          // CFI违规，终止程序
          terminate_process("CFI violation: invalid function pointer target");
      }
      func_ptr(); // 执行合法的间接调用
  }
  
  // 虚函数调用的粗粒度CFI类似，校验vtable中的目标函数地址
  void call_virtual_function_coarse(Base* obj, int vtable_offset) {
      void** vptr = *(void***)obj;
      void* target_func = vptr[vtable_offset];
  
      if (!g_valid_function_entries.contains(target_func)) {
          terminate_process("CFI violation: vtable target not a valid function entry");
      }
      // 执行调用
      // ((void(*)())target_func)();
  }

• 优缺点：

  • 优点： 性能开销相对较低，实现相对简单，能有效防御ROP/JOP攻击中将控制流劫持到非函数入口（如gadgets内部）的情况。
  • 缺点： 精度低。如果攻击者能够将控制流劫持到一个“合法”的函数入口，但该函数并非调用点预期的目标（例如，将Base::foo的调用重定向到Base::bar，如果Base::bar也是一个合法的函数入口），粗粒度CFI将无法检测。这使得攻击者仍能通过“类型混淆”的方式实现细粒度劫持。

方法二：细粒度CFI (e.g., LLVM’s kCFI, Microsoft’s CFG)

细粒度CFI旨在提供更强的保护，它不仅校验目标地址是否是合法函数入口，还校验目标函数的类型签名是否与调用点预期的签名严格匹配。

• 核心思想： 基于类型匹配。只有当目标函数的签名（参数类型、返回类型、调用约定）与调用点的预期签名完全匹配时才允许调用。

• 实现方式：

  • 编译时：
    • 编译器为程序中每一种独特的函数签名类型生成一个唯一的整数ID或哈希值。
    • 编译器在每个函数入口处插入一个标签或元数据，表示该函数的类型ID。
    • 编译器在每个间接调用点插入校验逻辑，用于获取目标函数的类型ID，并与调用点预期的类型ID进行比较。
  • 运行时：
    • 在执行间接调用前，校验代码会从目标函数的元数据中提取其类型ID。
    • 校验代码将提取到的类型ID与当前调用点预期的类型ID进行比较。
    • 如果类型ID不匹配，则认为发生CFI违规。

• 虚函数调用 (Virtual Function Calls) 的细粒度CFI：
  为了保护虚函数调用，编译器需要确保被调用的虚函数与vtable中预期的函数类型相符。
  一种常见的实现方式是在vtable中，除了存储实际的函数指针外，还存储对应的CFI标签。

  // 伪代码：编译器为每个函数类型生成一个唯一的CFI标签
  // 例如：
  // TYPE_ID_VOID_INT = hash("void(int)")
  // TYPE_ID_VOID_VOID = hash("void()")
  
  // 编译器对虚函数表进行修改（简化视图）
  // 原始vtable for Derived:
  //   [ptr to Derived::foo(int)]
  //   [ptr to Derived::bar()]
  
  // 加固后的vtable for Derived:
  //   [CFI_TAG for void(int)]   // CFI标签
  //   [ptr to Derived::foo(int)] // 实际函数指针
  //   [CFI_TAG for void()]    // CFI标签
  //   [ptr to Derived::bar()]   // 实际函数指针
  
  // 运行时插桩 (伪代码)
  class Base_CFI {
  public:
      // C++ ABI通常将vptr放在对象开头
      // 假设vtable结构是 {tag0, func0, tag1, func1, ...}
      // 且vtable_offset是相对于vtable开头的索引 (0 for first func, 2 for second, etc.)
      void cfi_virtual_call(int vtable_slot_index) {
          void** vptr = *(void***)this; // 获取vptr
          // 假设标签紧邻函数指针之前存储
          CFI_Tag expected_tag = (CFI_Tag)(vptr[vtable_slot_index]); // 获取预期的标签
          void* target_func = vptr[vtable_slot_index + 1];           // 获取目标函数指针
  
          // 从目标函数入口处获取其实际CFI标签（需要编译器在函数入口插入指令）
          CFI_Tag actual_tag = get_target_function_tag(target_func);
  
          if (expected_tag != actual_tag) {
              terminate_process("CFI violation: vtable hijack or type confusion detected");
          }
          // 执行调用 (这里需要根据实际函数签名进行类型转换和调用)
          // ((void(*)())target_func)();
      }
  };
  
  // 实际调用：
  // Derived* obj = new Derived();
  // obj->cfi_virtual_call(0); // 调用foo，vtable_slot_index 0 对应第一个函数及其标签

  这种方式确保了即使攻击者篡改了vtable中的函数指针，只要目标函数的类型签名与调用点预期的不符，CFI也能捕获。

• 函数指针调用 (Function Pointer Calls) 的细粒度CFI：
  函数指针的CFI更为复杂，因为它不依赖于固定的vtable结构。
  一种常见方法是使用“间接调用校验器”（Indirect Call Checker）。

  // 伪代码：函数指针CFI
  // 编译器在编译时为每种函数签名生成一个全局唯一的ID
  const uint64_t TYPE_ID_VOID_INT = 0x12345678; // hash("void(int)")
  const uint64_t TYPE_ID_VOID_FLOAT = 0x87654321; // hash("void(float)")
  
  // 编译器在每个函数入口处插入指令，将函数的类型ID存储在一个特殊的寄存器或TLS中
  // 或者，将类型ID与函数指针一起存储（例如，通过在指针的高位存储标签，或使用一个全局映射表）
  
  // 编译器对目标函数进行插桩
  void target_func_int(int a) {
      // 编译器在这里插入代码，设置当前函数的CFI类型ID
      // 例如：__cfi_set_current_type_id(TYPE_ID_VOID_INT);
      printf("Called target_func_int with %dn", a);
  }
  
  void target_func_float(float b) {
      // 编译器在这里插入代码，设置当前函数的CFI类型ID
      // 例如：__cfi_set_current_type_id(TYPE_ID_VOID_FLOAT);
      printf("Called target_func_float with %fn", b);
  }
  
  // 在运行时，编译器在函数指针调用点插入校验
  typedef void (*FuncPtr_VoidInt)(int);
  typedef void (*FuncPtr_VoidFloat)(float);
  
  void call_with_ptr_cfi(FuncPtr_VoidInt ptr, int arg) {
      // 运行时校验：
      // 获取目标函数的实际类型ID (例如，通过查询全局表，或者在指针低位/高位编码)
      // 假设有一个函数可以获取给定地址的CFI类型ID
      uint64_t actual_type_id = get_cfi_type_id_for_address((void*)ptr);
  
      if (actual_type_id != TYPE_ID_VOID_INT) {
          terminate_process("CFI violation: function pointer type mismatch");
      }
      ptr(arg); // 执行调用
  }
  
  int main() {
      FuncPtr_VoidInt f1 = target_func_int;
      call_with_ptr_cfi(f1, 100);
  
      // FuncPtr_VoidInt f2 = (FuncPtr_VoidInt)target_func_float; // 理论上类型不匹配
      // call_with_ptr_cfi(f2, 200); // 如果攻击者能强制转换并调用，CFI会捕获
      return 0;
  }

  get_cfi_type_id_for_address的实现是细粒度CFI的关键和难点。它可能通过在每个函数的入口处插入一个特殊的指令序列，或者在内存中维护一个地址到类型ID的映射表来实现。一些CFI实现会利用指令集中的特殊指令，或者将CFI标签编码到函数指针的高位（如果地址空间允许）。

• 优缺点：

  • 优点： 防护能力极强，能有效抵御利用类型混淆的JOP/ROP攻击，大大缩小了攻击者可利用的gadget集合。
  • 缺点： 性能开销显著增加，因为每次间接调用都需要进行类型ID的获取和比较。实现复杂度高，需要对编译器后端进行深入修改，并可能引入新的攻击面（例如，如果标签本身可以被篡改）。

V. 编译器加固：LLVM/Clang中的CFI实现

现代编译器如LLVM/Clang在CFI加固方面扮演着核心角色。它们利用编译器的中间表示（IR）层进行分析和插桩，从而实现平台和语言无关的CFI。

LLVM的CFI实现机制：

LLVM的CFI通常作为其Sanitizer家族（如ASan、MSan、TSan、UBSan）的一部分或独立模块实现。其中，kCFI (Kernel CFI) 或 SCFI (Software CFI) 是其主要形式。

1. LLVM IR层的插桩：
   CFI的插桩主要发生在LLVM的中间表示（IR）层。这意味着，CFI逻辑在代码被优化和转换为机器码之前就已经被插入，从而可以更好地利用编译器的全局分析能力。
   LLVM IR中的间接调用通常表示为call indirect或invoke indirect指令。

2. 识别间接调用点：
   LLVM编译器遍历IR，识别所有的间接调用指令，例如：

   • call %func_ptr(i32 %arg1)
   • call %vtable_entry(i8* %this_ptr)

3. 生成和管理CFI标签（__cfi_type_id）：

   • LLVM会为程序中每个具有独特函数签名（参数、返回类型、调用约定）的函数生成一个全局唯一的类型ID。这些ID通常是哈希值。
   • 对于每个函数，编译器会在其入口处插入一个特殊的指令序列或数据结构，用于存储其类型ID。例如，一个全局的__cfi_type_id表，或者在函数代码的开头插入一个mov指令来设置一个寄存器。
   • 对于虚函数，类型ID会被存储在vtable中，通常紧邻着函数指针。

4. 插入运行时校验（__cfi_check）：
   在每个间接调用点之前，LLVM会插入一个对运行时校验函数的调用。这个校验函数通常是__cfi_check或类似名称，它接收目标函数指针和期望的类型ID作为参数。

   LLVM IR伪代码示例：

   ; 定义一个函数类型，例如：void(i32)
   %func_type_void_i32 = type { void (i32)* }
   
   ; 假设有一个函数 target_func_int(int)
   define void @target_func_int(i32 %arg) {
       ; 编译器在此处插入代码，表示其类型ID
       ; 例如：store i64 <TYPE_ID_VOID_I32>, i64* @__cfi_current_type_id_slot
       ret void
   }
   
   ; 间接调用点
   define void @caller_function(void (i32)* %func_ptr, i32 %value) {
       ; 1. 获取期望的类型ID (编译时已知)
       %expected_type_id = call i64 @__cfi_get_type_id_for_signature(void (i32)*)
   
       ; 2. 调用CFI校验函数
       ; 这个校验函数会从 %func_ptr 指向的目标函数中获取其实际类型ID
       ; 并与 %expected_type_id 进行比较
       call void @__cfi_check_call(i64 %expected_type_id, void (i32)* %func_ptr)
   
       ; 3. 执行实际的间接调用
       call void %func_ptr(i32 %value)
       ret void
   }

   __cfi_check_call函数通常会在目标函数地址附近查找其类型ID。如果类型ID不匹配，它将调用一个陷阱（trap）函数或终止程序。

Microsoft Visual C++ 的 Control Flow Guard (CFG)：

Microsoft的Control Flow Guard (CFG) 是Windows操作系统和Visual C++编译器共同提供的一项安全功能，主要针对前向CFI。它在Windows 8.1 Update 3中首次引入。

• 原理： CFG在编译时为所有合法函数入口地址生成一个位图。在运行时，它会在每个间接调用点插入一个对_guard_check_icall_fptr函数的调用。
• _guard_check_icall_fptr： 这个函数是Windows操作系统提供的一个运行时检查函数。它接收目标函数指针作为参数，并查询内部的位图，判断该目标地址是否被标记为合法的间接调用目标。
• 特点：
  • 粗粒度： CFG主要是一个粗粒度的CFI机制。它只检查目标地址是否是一个合法的函数入口地址，而不检查其类型签名。这意味着，攻击者仍可能将控制流劫持到另一个具有不同语义但合法入口的函数，从而绕过CFG。
  • 与操作系统集成： CFG的检查逻辑由操作系统内核和用户态运行时库共同实现，能够有效地在硬件层面加速检查，减少性能开销。
  • 启用方式： 在Visual Studio中，通过/guard:cf编译器选项启用CFG。

VI. CFI的绕过与局限性

尽管CFI是强大的防御机制，但它并非完美无缺，仍存在潜在的绕过方法和局限性。

• 信息泄露： 如果攻击者能够通过其他漏洞（例如，格式化字符串漏洞、未初始化内存泄露）泄露出CFI标签、合法目标地址列表或CFG本身，那么他们就可以利用这些信息来构造“合法”的劫持路径，从而绕过CFI检查。
• 同类型函数（Type Confusions）： 细粒度CFI依赖于类型签名匹配。如果攻击者能够找到一个与预期目标函数具有完全相同类型签名（参数数量、类型、返回类型、调用约定）的恶意函数或gadget，即使功能完全不同，CFI也可能无法阻止这种劫持。例如，一个void(*)(int)的函数指针可能被劫持到另一个void(*)(int)的函数，即使它们的语义完全不相关。
• JIT编译： 动态代码生成（Just-In-Time compilation, JIT）系统在运行时生成和执行代码。由于这些代码在编译时不存在，CFI编译器无法对其进行静态分析和插桩。这使得JIT生成的代码成为CFI的盲点，攻击者可能利用JIT引擎本身来注入和执行恶意代码。
• 未覆盖的控制流： CFI主要保护间接控制流转移。对于直接调用（call target_address）和直接跳转（jmp target_address），CFI通常不进行检查。如果攻击者能够篡改这些直接跳转或调用指令的目标地址，CFI将无能为力。这需要更底层的内存保护机制（如代码段只读）来防御。
• 性能开销： 细粒度CFI的性能开销是一个持续的挑战。对于性能敏感的应用，即使是几个百分点的性能下降也可能难以接受。硬件辅助CFI旨在解决这一问题。
• 兼容性问题： 跨模块、跨库的CFI实现复杂性高。如果一个程序链接了未启用CFI的库，或者链接了使用不同CFI策略编译的库，可能导致运行时错误或安全漏洞。
• 标签篡改： 如果攻击者能够篡改存储CFI标签的内存区域（例如，vtable中的标签、函数入口处的标签），那么他们就可以伪造合法的标签，从而绕过校验。

VII. CFI的未来发展与与其他安全技术的结合

为了克服CFI的局限性并提高其效能，未来的发展方向主要集中在硬件辅助CFI和与其他内存安全技术的协同。

• 硬件辅助CFI (e.g., Intel CET, ARM PAC/BTI)：
  硬件辅助CFI旨在将部分或全部CFI校验逻辑转移到CPU硬件中执行，以显著降低性能开销并提高安全性。

  • Intel Control-flow Enforcement Technology (CET)： 包含两部分：
    • Shadow Stack (SS)： 针对后向CFI，通过在硬件层面维护一个独立的影子栈来存储返回地址，与主栈上的返回地址进行比较。如果两者不匹配，则检测到ROP攻击。
    • Indirect Branch Tracking (IBT)： 针对前向CFI，通过在合法间接跳转目标处放置特殊的“END_BRANCH”指令来标记。间接跳转指令在跳转前会检查目标地址是否以END_BRANCH指令开头。如果不是，则认为是非法跳转。
  • ARM Pointer Authentication Codes (PAC) / Branch Target Identification (BTI)：
    • PAC： 通过密码学哈希对指针（包括返回地址和函数指针）进行签名，并将签名存储在指针的未使用位中。在指针使用前，硬件会重新计算签名并与存储的签名进行比较。如果签名不匹配，则认为指针已被篡改。这可以防御ROP和JOP。
    • BTI： 类似于Intel的IBT，通过在合法分支目标处放置特殊的“BTI”指令来标记。间接分支指令会检查目标是否被BTI标记。
      硬件辅助CFI的优势在于性能开销极低，且难以被纯软件攻击绕过。它与软件CFI可以形成强大的协同防御体系。

• 与其他内存安全技术结合：
  CFI并非银弹。它需要与其他内存安全技术结合使用，形成多层次的防御体系：

  • Memory Tagging (MTE)： 如ARM Memory Tagging Extension。通过对内存分配和指针进行标签化，防止越界访问、Use-After-Free等问题，从而从根本上减少CFI所需的间接跳转点的暴露。
  • 沙箱技术： 将不可信的代码隔离在受限的环境中执行，即使CFI被绕过，攻击者也难以对整个系统造成破坏。
  • 类型安全强化： 进一步加强语言的类型安全性，减少类型混淆的机会。
  • 内存安全语言： 鼓励使用Rust等默认提供内存安全保证的语言，从根本上杜绝内存安全漏洞。

• CFI在嵌入式系统和IoT设备中的应用前景：
  嵌入式系统和IoT设备通常资源受限，但同样面临严峻的安全挑战。轻量级CFI实现或硬件辅助CFI在这些场景中具有巨大的应用潜力，可以有效提高这些设备的安全性，抵御日益增长的网络攻击。

VIII. 增强软件弹性，抵御高级威胁

控制流完整性（CFI）是现代软件安全架构中不可或缺的一环，它通过间接跳转表校验，在编译器层面加固程序，有效防御了高级内存劫持攻击。从粗粒度到细粒度，从软件实现到硬件辅助，CFI技术不断演进，旨在为C++等低级语言提供更坚实的安全保障。虽然存在局限性，但与其他内存安全技术协同，CFI将持续提升软件的弹性，抵御日益复杂的网络威胁。