Clang的CFI通过编译期剔除非法间接调用目标来阻断ROP，运行时仅允许跳转到同类型签名的已知函数地址；它不防护ret指令、sigreturn/setcontext及数据流劫持，且要求全量编译以避免签名不匹配。
CFI 在 Clang 中如何实际阻断 ROP 链构造
Clang 的 CFI（Control Flow Integrity）不是靠“检测异常跳转”来防 ROP，而是编译期就**砍掉非法间接调用的合法目标**。它不阻止你跳，而是让绝大多数 gadget 失去被 call/jmp 到的资格——因为那些地址根本不在 CFI 允许的 target set 里。
- 启用
-fsanitize=cfi后，所有虚函数调用、函数指针调用、成员函数指针调用都会插入运行时检查，只允许跳转到同一类型签名的、编译期已知的函数地址 - 关键点：CFI 不保护 ret 指令本身（那是 Shadow Stack 或 CET 的事），但它让
call *%rax这类指令在跳向伪造的 gadget 地址时直接 abort，因为 %rax 指向的地址未通过类型签名验证 - 典型失败现象：
runtime error: control flow integrity check for type 'void (int)' failed (0x7f... != 0x55...)—— 这不是警告，是进程立即终止
为什么虚函数表劫持在 CFI 下大概率失效
传统 vtable 覆盖攻击依赖将虚函数指针替换成 gadget 地址，但 CFI 会强制校验每次虚调用的目标是否属于该虚函数声明的 exact 类型签名。哪怕你覆盖了 vtable 项，只要目标地址没被编译器标记为“可作为该虚函数的实现”，调用就会崩溃。
- Clang 对每个虚函数生成唯一 type identifier（基于函数签名哈希），vtable 条目存储的是带 signature 标签的函数指针，而非裸地址
- 即使你用堆喷控制了 vtable 内存，覆盖进去的 gadget 地址无法通过 runtime signature check，
vptr->foo()会在进入 foo 前就触发cfi-check-failure - 注意：CFI 默认不保护纯函数指针（如
void (*fp)() = &gadget;），除非启用-fsanitize=cfi-icall显式开启间接调用检查
-fsanitize=cfi-icall 和 -fsanitize=cfi-vcall 的区别与坑
这两个开关控制不同粒度的检查，开错组合会导致漏防或误杀，且影响性能和链接行为。
-
-fsanitize=cfi-vcall：只检查虚函数调用（vtable lookup + call），开销较小，兼容性好，是 CFI 最常用子集 -
-fsanitize=cfi-icall：检查所有间接调用（call *%rax形式），包括函数指针、回调、dlsym 返回值等，但要求整个程序（含所有 .so）都用相同 CFI 签名编译，否则dlopen会失败或调用崩溃 - 常见错误：只给主程序加
-fsanitize=cfi-icall，但链接的第三方库没重编译 → 运行时报undefined symbol: __cfi_check或直接 abort - 必须全量编译：静态库、动态库、主程序都要用相同 Clang 版本 + 相同 CFI flag 编译，否则类型签名不匹配
CFI 无法防御的 ROP 场景（别误信“开了 CFI 就安全了”）
CFI 是强约束，但不是万能盾。它对某些 ROP 利用路径完全无感，尤其当攻击不依赖间接跳转时。
立即学习“C++免费学习笔记（深入）”；
- 不检查
ret指令：栈上布置好 gadget 链后单纯靠 ret 指令“滑动”，CFI 完全不干预（需 CET / Shadow Stack 补位） - 不防护信号上下文切换：若攻击者触发
sigreturn或setcontext，直接重写寄存器状态，绕过所有 CFI 插入的检查点 - 不处理数据流劫持：比如篡改
std::string的内部指针导致后续memcpy覆盖关键内存，这类非控制流篡改 CFI 不管 - 最易忽略的一点：CFI 默认不验证
longjmp目标，除非额外启用-fsanitize=cfi-jump（Clang 15+），且仍不覆盖所有 setjmp/longjmp 变体
CFI 的真正价值在于大幅提高 ROP 开发门槛——它逼攻击者要么放弃通用 gadget，要么转向更难利用的内核态或 JIT 绕过路径。但只要存在一个未受保护的间接调用点，或一个未启用 CFI 的共享库，整条防线就可能松动。
