AARCH64 Branch Target Identification防御攻击

原创于 2025-12-04 14:07:06 发布 · 296 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#BTI # AARCH64 # ARMv8.5-A

AI助手已提取文章相关产品：

AARCH64架构下的安全新范式：从BTI机制到全栈防护实践

在智能设备无处不在的今天，处理器早已不只是“算力”的代名词，更是一道守护数据与系统的隐形防线。然而，随着攻击技术的演进，传统的防御手段如NX（不可执行）、ASLR（地址空间布局随机化）正逐渐显得力不从心——ROP、JOP这类代码重用攻击已经能绕过静态保护，悄然改写程序的控制流。

就在这场攻防拉锯战中，ARMv8.5-A带来了一个转折点： 分支目标识别 （Branch Target Identification, BTI）。它不是简单的补丁，而是一种全新的硬件级控制流完整性（CFI）范式。通过在合法跳转入口插入一条特殊指令 bti ，处理器就能在取指阶段判断“你是不是该来这儿”，一旦发现非法跳转，立即触发异常，从根本上掐断攻击链。

这听起来像魔法？其实不然。它的核心思想非常朴素： 只允许从“门”进去，不允许翻墙 。而这个“门”，就是那条不起眼的 bti 指令。

BTI的本质：不是检测，是拦截

很多人误以为BTI是一种运行时监控机制，类似软件CFI那样插桩检查。但真相是—— BTI根本不需要“检查” 。它更像是一个自动门禁系统：你在门口刷了卡（即跳转到带有 bti 前缀的地址），门就开；没刷卡？直接报警。

这种机制的关键在于 硬件集成 。当CPU执行一条间接跳转指令（比如 blr x16 ）时，流水线前端会同步完成以下动作：

计算目标地址；
查页表确认该页是否启用了BTI保护；
预取目标地址的第一条指令；
判断这条指令是不是有效的 bti 操作码。

如果一切合规，继续执行；否则，瞬间抛出一个同步异常（Instruction Abort），连那条指令都还没来得及解码，攻击就已经被扼杀在摇篮里。

🚨 想象一下：你精心构造了一串ROP gadget，终于找到了system()函数的地址，满怀期待地让程序跳过去……结果，“啪”一声，SIGILL信号直接把你干掉。连shell都没见着，游戏结束。

这就是BTI的力量：零延迟、零逃逸窗口、纯硬件实现。

BTI指令长什么样？真的只是NOP吗？

先来看一组真实的编码：

指令	32位十六进制编码	含义
`bti c`	`0xD503203F`	允许调用/返回类跳转（如 `blr` ）
`bti j`	`0xD503207F`	仅允许跳转型跳转（如 `br` ）
`bti jc`	`0xD50320BF`	兼容两种跳转方式
`bti`	`0xD50320FF`	等价于 `bti c`

这些指令在功能上确实是“空操作”——它们不会改变寄存器状态，也不会影响后续逻辑。但从处理器角度看，它们却是至关重要的“身份标签”。

举个例子：

my_function:
    bti c                    // 我是合法入口！欢迎光临～
    stp x29, x30, [sp, -16]!
    mov x29, sp
    sub sp, sp, #32
    ...

如果你试图把控制流导向 my_function + 4 ，也就是 stp 那条指令的位置，哪怕那条指令本身完全合法，也会因为前面没有 bti 前缀而导致异常触发。

🧠 小知识 ：为什么要有 c 和 j 之分？

bti c 多用于函数入口，接受来自 bl 或 blr 的调用。
bti j 常出现在 switch 语句生成的跳转表目标处，通常由 br 指令直接跳转而来。
使用细分类型可以减少误报，比如防止某个本应只能被 br 访问的跳转点被 blr 误触。

编译器会根据上下文自动选择最合适的变体，开发者几乎无需干预。

硬件怎么知道“该不该查”？页表说了算！

你以为只要写了 bti ，CPU就会永远检查？错。BTI的启用是有条件的，而且这个条件藏在 页表项 里。

ARMv8.2-A引入了一个扩展属性位，常被称为“PXN bit + BTI flag”。也就是说，只有当某一页在映射时明确声明“我这里有BTI指令”，处理器才会对该页内的跳转实施验证。

Linux内核就是这样做的：

pte_t pte = pte_mkexec(pte_wrprotect(pfn_pte(pfn, PAGE_KERNEL)));
if (is_kernel_text(addr))
    pte = pte_mkpxn(pte);  // 同时激活PXN和BTI感知
set_pte_at(&init_mm, addr, ptep, pte);

这里的 pte_mkpxn() 不仅设置了特权级不可执行（PXN），还悄悄告诉MMU：“这片代码要用BTI保护，请开启检查模式。”

这意味着什么？

✅ 正常的 .text 段会被严格校验；
❌ 而攻击者试图写入的RWX内存（比如shellcode注入堆或栈），即使绕过了W^X策略，只要没加 bti 前缀，照样无法执行。

🎯 所以说，BTI + NX 的组合，才是真正意义上的“写即死”：你能写的地方不能执行，能执行的地方你不能乱写。

异常来了怎么办？别怕，系统早有准备

当BTI触发异常时，处理器会进入EL1（内核态），跳转到预设的异常向量。这时候，操作系统就得接住这个“球”。

在Linux中，你可以看到这样的处理逻辑：

void handle_instruction_abort(struct pt_regs *regs) {
    unsigned int esr = read_sysreg(esr_el1);
    unsigned long far = read_sysreg(far_el1);

    if ((esr & ESR_ELx_EC_MASK) == ESR_ELx_EC_BT_MISS) {
        pr_alert("💥 BTI violation at address: %lx\n", far);
        pr_alert("Offending instruction at: %lx\n", regs->pc);
        force_sig(SIGILL);  // 给用户进程发个“非法指令”信号
    }
}

这段代码干了三件事：

读取异常综合征寄存器（ESR），确认是BTI违例（EC=0b100110）；
获取跳转目标地址（FAR），用于日志记录或取证分析；
向出问题的进程发送 SIGILL ，终止其运行。

💡 这意味着：一次失败的ROP尝试，可能只会导致应用崩溃，而不会让整个系统宕机。安全边界依然牢固。

而且，现代调试工具（如GDB、perf）也能捕获这类事件，帮助开发人员定位潜在漏洞。甚至可以在生产环境中结合eBPF程序做实时告警，构建主动防御体系。

编译器才是幕后英雄：默默帮你加 `bti`

你说BTI靠硬件？没错。但如果没有编译器配合，它就是个摆设。

好在主流编译器早就支持了自动化注入。GCC 9.1+ 和 LLVM 10+ 都提供了统一选项：

# GCC
gcc -march=armv8.5-a+bti \
    -mbranch-protection=standard \
    -c example.c -o example.o

# Clang
clang -target aarch64-linux-gnu \
      -mbranch-protection=bti-call,bti-jump \
      -c example.c -o example.o

其中 -mbranch-protection=standard 是推荐配置，等价于同时启用 bti-call 和 bti-jump ，覆盖绝大多数间接跳转场景。

那编译器到底在哪加？答案是：

✅ 加的地方：

函数入口（包括虚函数）
switch跳转表的目标地址
函数指针调用点
computed goto（GNU扩展）

❌ 不加的地方：

直接调用（ call func ）——不需要，路径固定
数据段、堆内存 —— 本来就不该执行

举个LLVM IR的例子：

define void @case_0() {
entry:
    bti c
    ret void
}

到了汇编层就会变成：

case_0:
    d503203f  bti c
    d65f03c0  ret

整个过程对开发者透明，无需修改一行C/C++代码。

不过要注意：某些高级特性（如 setjmp/longjmp 、异常展开）涉及非标准控制流转移，可能会绕过BTI。为此，编译器会对运行时库中的关键入口进行特别标记，确保它们也受保护。

性能怎么样？几乎感觉不到！

很多人一听“安全机制”就担心性能损失。但BTI不一样。

因为它所有的检测都在 取指阶段并行完成 ，根本不占用额外指令周期。实验数据显示，在SPEC CPU2017基准测试中，单独启用BTI带来的平均性能损耗仅为 ~1.2% ，远低于传统软件CFI方案（>15%）。

相比之下，PAC（指针认证）由于需要计算签名/验证，开销更大一些（约3.5%）。但如果两者一起用呢？

配置	平均性能损失	适用场景
无保护	0%	测试环境
BTI-only	~1.2%	通用服务器、移动应用
PAC-only	~3.5%	安全敏感模块
BTI+PAC	~4.8%	政府、金融、车载系统
BTI+PAC+StackGuard	~6.1%	关键基础设施

看到了吗？即便是最强组合，也才不到7%。对于现代应用场景来说，这点代价换来的是 攻击面压缩98%以上 的回报，简直不要太划算 😎。

动态链接怎么办？旧库没BTI岂不是要崩？

这是个好问题。现实中不可能所有模块都是新编译的。万一主程序开了BTI，却加载了一个老版本的glibc，会发生什么？

ARM想到了这一点。ELF文件可以通过 .note.gnu.property 段声明自己的属性：

struct property_note {
    uint32_t namesz;     // 名称大小
    uint32_t descsz;     // 描述符大小
    uint32_t type;       // NT_GNU_PROPERTY_TYPE_0
    char name[4];        // "GNU"
    struct {
        uint32_t pr_type;   // GNU_PROPERTY_AARCH64_FEATURE_1_AND
        uint32_t pr_datasz; // 4
        uint32_t features;  // BIT(0): BTI enabled
    } desc;
};

动态链接器（如glibc的ld.so）在加载so时会检查这个标志：

主程序	库	行为	安全性
有BTI	无BTI	调用时不检查	存在绕过风险
无BTI	有BTI	忽略BTI属性	浪费资源
有BTI	有BTI	正常执行BTI检查	✅ 安全
无BTI	无BTI	无保护	❌ 高风险

所以最佳实践是： 统一构建链 ，确保所有组件都启用相同级别的保护。

幸运的是，Android 12+、Fedora 35+ 等主流系统已经开始默认启用BTI，生态正在快速跟进。

内核也要保护！Linux是怎么做的？

既然用户空间要防，内核更不能落下。毕竟一旦内核被攻破，整个系统就完了。

Linux从5.8版本开始正式支持BTI。启用路径如下：

🔧 第一步：配置Kconfig

config ARM64_BTI
    bool "Enable Branch Target Identification (BTI)"
    depends on CPU_BIG_ENDIAN && !COMPAT || !CPU_BIG_ENDIAN
    depends on ARM64_PTR_AUTH_KERNEL || !ARM64_PTR_AUTH

开启后，构建系统会在汇编代码中插入必要的 bti 指令。

🧱 第二步：启动初期就要稳住

系统刚启动时，很多初始化代码还没准备好。如果这时就启用BTI，可能导致自检失败。因此，Linux采用渐进式策略：

__primary_switched:
    bti c                      // 在这里插入第一道门禁
    adrp    x0, init_thread_union
    add     x0, x0, #THREAD_START_SP
    mov     sp, x0
    b   start_kernel

__primary_switched 可能被虚拟机模拟跳转到达，所以必须加 bti c 。

🔐 第三步：关键入口全面加固

系统调用、中断服务例程这些高频接口更是重点防护对象：

el0_syscall:
    bti j               // 允许jump-type跳转
    stp x29, x30, [sp, #-16]!
    mov x29, sp
    // ... handle syscall ...

同样，中断向量表也加上了 bti c ：

vector_irq_primary:
    bti c
    irq_handler lr

这样一来，即便攻击者通过某种漏洞拿到了内核控制权，想跳到任意gadget执行，也会因为缺少 bti 前缀而失败。

Android实战：ART、Zygote全都上了BTI！

移动端的安全压力更大，Google显然也意识到了这点。

从Android 12起，AOSP主线已为多个核心组件默认启用BTI：

🤖 ART运行时（libart.so）

作为Java字节码的执行引擎，ART高度动态，极易成为JIT-ROP攻击的目标。现在它的构建配置是这样的：

cc_library {
    name: "libart",
    target: {
        android_arm64: {
            arch: {
                branch_protection: "bti",
            }
        }
    }
}

等价于 -mbranch-protection=bti ，自动为每个函数入口插入 bti c 。

👶 Zygote进程

所有App的父进程，权限极高。一旦被劫持，后果严重。现在它也被加上了双重保险：

cc_binary {
    name: "zygote",
    target: {
        android_arm64: {
            arch: {
                branch_protection: "bti,pac-ret",
            }
        }
    }
}

👉 bti 防止非法跳转
👉 pac-ret 保护返回地址不被篡改

双管齐下，连高级ROP都难施展拳脚。

🛡️ 其他守护进程

进程	是否启用BTI	备注
`/init`	✅ 是	第一个用户空间进程
`surfaceflinger`	✅ 是	图形合成服务
`netd`	✅ 是	网络管理
`keystore`	⚠️ 部分	正在迁移中

可见，高权限服务基本已完成BTI覆盖。

怎么验证BTI真的生效了？三招教你自查

纸上谈兵不行，得动手验证。

✅ 方法一：看ELF属性

readelf -A /system/lib64/libc.so

输出应包含：

Tag_branch_target_isa: BTI

说明该二进制声明支持BTI。

✅ 方法二：反汇编找 `bti` 指令

objdump -d /system/bin/init | grep -A2 "bti"

典型输出：

400120: d503233f    bti j
400124: a9bf7bfd    stp x29, x30, [sp, #-16]!
400128: 910003fd    mov x29, sp
--
4002a0: d503231f    bti c
4002a4: a9be7bfd    stp x29, x30, [sp, #-32]!

👉 bti j 多见于跳转表
👉 bti c 多见于函数入口

若大量函数缺失，可能是编译配置遗漏。

✅ 方法三：写个Python脚本批量扫描

import lief

def check_bti(elf_path):
    binary = lief.parse(elf_path)
    attrs = binary.properties
    for attr in attrs:
        if attr.type == lief.ELF.DYNAMIC_TAGS.ARM_BRANCH_TARGET_ENFORCED:
            return True
    return False

# 批量检查系统镜像
for lib in system_libs:
    if not check_bti(lib):
        print(f"⚠️ {lib} missing BTI!")

这类自动化检查完全可以集成进CI/CD流水线，实现持续合规监控。

实战演练：构造ROP payload试试水？

来吧，咱们做个实验。

假设有个栈溢出漏洞，你想跳到 system("/bin/sh") 。常规操作是：

rop = [
    pop_r0_ret,
    sh_str_addr,
    system_addr
]

但在BTI环境下，只要 system_addr 指向的地址不是以 bti c 开头， blr x16 一执行，立刻触发异常。

用GDB看看发生了什么：

(gdb) x/5i $pc-8
=> 0xffff000040001a: blr x16
(gdb) info registers x16
x16            0xffff00008000  <system@plt>
(gdb) x/1wx 0xffff00008000
0xffff00008000: 0x94000000   ← 这不是bti指令！

Boom 💥，直接进异常处理流程。

除非你能找到一个既满足功能需求、又带 bti 前缀的gadget，否则这条路走不通。

而现实是：BTI启用后，可用gadget数量锐减98%以上。想要凑出完整攻击链？难如登天。

BTI + PAC = 黄金搭档

说到这儿，不得不提另一个明星机制： 指针认证 （PAC）。

如果说BTI是“门卫”，那PAC就是“锁钥匙”：

PAC ：保护返回地址不被篡改 → 防止 ret 被劫持
BTI ：保护跳转目标必须合法 → 防止 br/blr 乱跳

二者结合，形成闭环防护：

secure_func:
    paciasp              // 对返回地址签名
    stp    x29, x30, [sp, #-16]!
    mov    x29, sp
    bti    c             // 标记为合法入口
    // 实际逻辑...
    autiasp              // 验证返回地址
    ret

攻击者现在面临双重难题：

🔐 想改返回地址？PAC签名对不上， ret 直接崩；
🚪 想跳到任意gadget？BTI没前缀， br 直接拦。

除非你能同时破解PAC密钥+手动注入含 bti 的恶意页，否则休想突破。

而在现代系统中，PAC密钥每次启动都会随机化，且无法泄露，这让攻击几乎不可能成功。

CI/CD中如何强制推行BTI？

安全不能靠自觉。要在团队中落地BTI，必须把它变成“准入门槛”。

🔄 GitHub Actions 示例

- name: Check BTI presence
  run: |
    if ! objdump -d $BINARY | grep -q "bti"; then
      echo "❌ No BTI instructions found!"
      exit 1
    fi
    if ! readelf -W -a $BINARY | grep -q "BTI Protected"; then
      echo "❌ Missing GNU_PROPERTY_AARCH64_FEATURE_1_BTI"
      exit 1
    fi
    echo "✅ Binary is BTI-compliant"

🔍 静态分析预警

Clang可以配合CodeQL规则，在PR审查阶段提示：

“⚠️ 函数dispatcher()通过函数指针调用目标，建议启用-mbranch-protection”

甚至可以根据调用上下文评分，标记“高危未防护路径”。

📊 安全审计量化指标

企业级平台可建立以下KPI：

指标	计算公式	目标值
BTI覆盖率	含 `bti` 的函数数 / 总可达函数数	>95%
高危模块防护率	已启用BTI的关键模块占比	100%
第三方库兼容性	外部so中携带BTI属性的比例	>90%

定期生成报表，推动整改优先级。