ARM PAC & BTI：内存安全硬件防护工程实战

一、引言：内存安全的持久战争

根据 Google Project Zero 的统计，约 70% 的 CVE 安全漏洞源于内存安全问题。从经典的缓冲区溢出到类型混淆、释放后重用 (Use-After-Free) 和越界读写，C/C++ 程序的内存安全威胁始终是安全领域的核心战场。

传统缓解措施——ASLR、Stack Canary、DEP/NX、CFI——在攻防对抗中不断被突破。ASLR 面对信息泄露形同虚设，Stack Canary 可被逐字节爆破，粗粒度 CFI 在复杂的面向返回编程 (ROP) 攻击面前无能为力。硬件厂商终于意识到：必须从指令集层面提供原生的指针完整性保护。

ARMv8.3-A 引入的 Pointer Authentication (PAC) 和 Branch Target Identification (BTI) 正是这一思路的产物。不同于软件方案的补丁式防御，PAC/BTI 直接在硬件层面为指针和间接跳转提供密码学保护与类型校验，从根本上瓦解 ROP/JOP 攻击链。

二、PAC 核心机制：让指针携带密码学签名

2.1 问题本质：被篡改的返回地址与函数指针

ARM64 架构中，函数调用通过 BL (Branch with Link) 指令实现，返回地址保存在 x30 (Link Register) 中。叶子函数（不再调用其他函数的函数）通常不需要保存 x30，但任何内存写漏洞都可能覆盖栈上的返回地址。当 RET 指令执行时，CPU 从 x30 获取返回地址——攻击者只需控制这个值就能劫持控制流。

PAC 的核心思想很简单：在指针的高位嵌入一个密码学签名，每次使用前进行验证。如果指针被篡改，验证失败将触发异常，攻击者在劫持前就被拦截。

2.2 QARMA 轻量级分组密码

PAC 使用 QARMA (QUAd Rouned Mifare-lightweight Authenticator) 算法计算签名。QARMA 是一种基于 Even-Mansour 构造的分组密码，专门为 ARM 的硬件低延迟需求设计：

• 分组长度：64 位（与指针宽度一致）
• 密钥长度：128 位
• 轮数：7 轮 QARMA-64（指针签名）或 11 轮 QARMA-128（通用签名）
• 延迟目标：1-2 个时钟周期内完成签名/验证

QARMA 的轻量级特性使得 PACIA/AUTIA 等指令可以在一个 ALU 周期内完成而不影响流水线吞吐。

2.3 PAC 密钥体系

ARM 架构提供 5 个独立的 128 位 PAC 密钥，由 EL1（内核）管理，EL0（用户态）无法读取：

密钥名称	用途	示例场景
APIAKey	A 域指令指针签名	返回地址 (LR 签名)
APIBKey	B 域指令指针签名	独立返回地址空间的 B 密钥
APDAKey	A 域数据指针签名	数据指针保护
APDBKey	B 域数据指针签名	独立域数据保护
APGAKey	通用密钥	任意数据 PACGA 计算

操作系统的内核在进程切换时轮换这些密钥，确保每个进程的 PAC 签名独立——攻击者即使获得一个进程的签名密钥也无法跨进程利用。

2.4 关键指令详解

; 指针签名 (Pointer Authentication Code Insert)
PACIA    Xd, Xn       ; 使用 APIAKey 和 Xn(上下文) 对 Xd 返回地址签名
PACIB    Xd, Xn       ; 使用 APIBKey 对 Xd 签名（用于非返回地址场景）
PACDA    Xd, Xn       ; 使用 APDAKey 对数据指针签名
PACDB    Xd, Xn       ; 使用 APDBKey 对数据指针签名
PACGA    Xd, Xn, Xm   ; 使用 APGAKey 对 Xn 签名，结果存入 Xd
AUTIA    Xd, Xn       ; 使用 APIAKey 验证 Xd 的 PAC，上下文为 Xn
AUTIB    Xd, Xn       ; 使用 APIBKey 验证 Xd 的 PAC
AUTDA    Xd, Xn       ; 使用 APDAKey 验证数据指针
AUTDB    Xd, Xn       ; 使用 APDBKey 验证数据指针

; 剥离 PAC（调试器/序列化场景需清除高位）
XPACI    Xd            ; 剥离指令指针的 PAC
XPACD    Xd            ; 剥离数据指针的 PAC

; 叶子函数快速指令（隐式使用 SP）
PACIASP                 ; 签名 LR 并使用 SP 作为上下文
AUTIASP                 ; 验证 LR 的 PAC

PACIA Xd, Xn 的密码学操作（简化描述）：

PAC = QARMA_Encrypt(APIAKey, XOR(PAC_Field_in_Pointer, Xn))
Pointer_with_PAC = Pointer_low_bits | (PAC << 56)

Xn 参数称为 modifier（盐值），可以是栈指针 (SP) 或虚拟地址，确保签名与特定上下文绑定。

2.5 指针布局与 TCR_EL1 配置

启用 PAC 后，64 位指针被重新划分：

63    56 55                 0
┌──────┬─────────────────────┐
│ PAC  │   有效地址 bits     │
│ 8bit │                     │
└──────┴─────────────────────┘

TSC_EL1 寄存器控制 PAC 位宽的配置，给操作系统在高地址区消耗与签名强度之间做权衡：

// 8-bit PAC: 抗暴力破解强度 2^8 = 256
// 16-bit PAC: 抗暴力破解强度 2^16 = 65536（代价）

三、BTI：间接跳转的着陆点验证

3.1 JOP 攻击面分析

Jump-Oriented Programming (JOP) 通过间接跳转指令（BR Xn）实现控制流劫持。与 ROP 依赖返回地址不同，JOP 的目标是函数指针、虚表指针、过程链接表 (PLT) 等任何通过寄存器间接跳转的位置。

核心问题：你永远不知道某次 BR Xn 应该跳转到哪里。

BTI 引入了一种新的着陆点标记概念：只有编译器标注为"合法跳转目标"的位置才允许间接跳转到达。

3.2 BTI 指令与分类

BTI 指令只有三种形式，均为复合条件分支：

BTI c    ; 仅允许间接调用 (BLR, BLRR) 着陆
BTI j    ; 仅允许间接跳转 (BR, BRR) 着陆
BTI jc   ; 允许间接调用和间接跳转着陆（最宽松）

关键行为规则： - 当间接跳转 (BR Xn) 执行时，CPU 检查目标地址的指令是否是有效的 BTI 指令 - BTI c 作为着陆点只接受间接调用 - BTI j 作为着陆点只接受间接跳转 - BTI jc 作为着陆点接受两者 - 非法着陆将触发 BRK #16 (蓝屏/kernel panic)

3.3 编译器协作模型

Clang/GCC 通过 -mbranch-protection 标志启用 BTI：

-mbranch-protection=standard      # pac-ret+bti (默认值)
-mbranch-protection=bti           # 仅 BTI
-mbranch-protection=pac-ret       # 仅 PAC 返回地址保护
-mbranch-protection=pac-ret+bti   # 全保护

启用后，编译器在每个函数入口插入 BTI c 指令：

; 函数入口
my_function:
    BTI c           ; 标记为合法间接调用目标
    STP  x29, x30, [sp, #-32]!
    MOV  x29, sp
    ; ... 函数体 ...
    LDP  x29, x30, [sp], #32
    AUTIASP         ; 验证 LR
    RET             ; 安全返回

对于函数内部的局部跳转（B 指令、条件分支），编译器不会进行 BTI 检查。BTI 仅验证间接跳转目标——这正是其低开销的根源。

3.4 BTI 在 Apple 生态的强制应用

Apple A12+ 芯片 (ARMv8.3) 首次在移动端全面启用 PAC+BTI，称为 arm64e 架构：

• iOS 14 / macOS 11+：所有系统二进制强制 arm64e
• PAC 应用：
• objc_msgSend 的 Cache 散列表中 IMP 指针全部签名
• ObjC 方法缓存重建 (cache rebuild) 时克隆 PAC
• ptrauth 签名用于所有编译后的函数指针
• 部署影响：
• JIT 引擎需格外小心（JavaScriptCore 使用 pacibsp）
• 内核态与用户态使用独立密钥
• 完全禁止混合 arm64/arm64e 执行

四、Linux 内核 PAC 实践

4.1 内核配置项

CONFIG_ARM64_PTR_AUTH=y          # 内核 PAC 支持
CONFIG_ARM64_PTR_AUTH_KERNEL=y   # 内核自身启用 PAC
CONFIG_CC_STACKPROTECTOR=y       # 栈保护（与 PAC 互补）

4.2 内核返回地址保护

当 CONFIG_ARM64_PTR_AUTH_KERNEL=y 时，内核编译器为每个内核函数自动插入 paciasp / autiasp。这意味着：

// 内核函数 prologue 展开：
// __entry(symbol):
//   paciasp          ; LR 签名 (使用 SP 作为 salt)
//   sub sp, sp, #frame_size
//   
// __entry_return:
//   autiasp          ; LR 验证
//   ret              ; 安全返回

这使内核栈中保存的返回地址具备密码学完整性，攻击者通过内核栈溢出无法直接篡改返回地址。

4.3 密钥轮换策略

内核通过 MSR APIAKeyLo_EL1, Xn 指令在进程切换时加载新密钥：

// kernel/entry.S 中进程切换路径
// 1. 从 task_struct 读取进程的 5 个 PAC 密钥
// 2. 通过 MSR 指令写入 APIAKey..APGAKey_EL1
// 3. 更新 TCR_EL1 的 PAC 配置位

关键设计：密钥元数据保存在内核地址空间，用户态 (EL0) 无法通过任何 MSR/MRS 指令读取。即使发生任意读漏洞，攻击者也难以直接获取 PAC 密钥。

4.4 Android 内核 PAC

Android 12 开始强制要求内核编译启用 PAC：

• Pixel/其他旗舰机：内核返回地址 100% PAC 保护
• 厂商适配：Qualcomm SM8350+、Tensor G2+ 等均支持
• 与 CFI 协同：当 LTO+CFI 锁定间接调用目标集时，PAC 额外加密验证目标指针完整性

五、实战编程：PAC 与 BTI 的代码级集成

5.1 内联汇编实现指针签名（教学示例）

#include <stdint.h>

// 使用 APIKey A 对指针签名（指令指针类）
static inline void* ptrauth_sign_unauthenticated(void* ptr, uint64_t key, uint64_t salt) {
    void* result = ptr;
    __asm__ __volatile__(
        "MOV  X16, %0\n\t"      ; X16 = ptr
        "MOV  X17, %2\n\t"      ; X17 = salt
        "PACIA X16, X17\n\t"    ; 签名
        "MOV  %0, X16\n\t"      ; 返回签名后的值
        : "=r"(result)
        : "0"(ptr), "r"(salt)
        : "x16", "x17"
    );
    return result;
}

// 模拟的密钥句柄
handle_t create_authenticated_callback(callback_fn fn, void* context) {
    uint64_t salt = (uint64_t)context ^ (uint64_t)fn;
    return (handle_t)ptrauth_sign_unauthenticated(fn, 0, salt);
}

5.2 类型安全的虚表保护（C++）

class SecurityCriticalBase {
public:
    virtual void process_sensitive_data() = 0;
    virtual void audit_log(const char* event) = 0;

protected:
    // 编译器在构造函数中为 vptr 签名
    // 每次虚调用前自动验证 PAC
    SecurityCriticalBase() = default;
};

class DataProcessor : public SecurityCriticalBase {
public:
    void process_sensitive_data() override {
        // vptr PAC 已被 AUTI 验证
    }
};

// 攻击场景模拟：
// 1. 漏洞覆盖对象 vptr
// 2. 下次虚调用 → vptr PAC 验证失败 → SIGSEGV

5.3 运行时性能影响分析

优化级别	函数调用开销增加	BTI 指令开销	总体 IPC 影响
-mbranch-protection=pac-ret	+2 cycle (paciasp+autiasp)	N/A	~0.3%
-mbranch-protection=bti	0	1 BTI/函数入口	~0.1%
-mbranch-protection=standard	+2 cycle	1 BTI/函数入口	~0.5%
手动数据指针签名	+2-4 cycle/pointer	N/A	视密度而定

六、防御机制局限与对抗实践

6.1 PAC 密钥泄露攻击

虽然 PAC 密钥存储在特权寄存器中，但以下信息泄露路径已被研究证实：

侧信道泄漏（Spectre-BTI 后续影响）：

// 恶意工作线程猜测其他线程的 PAC 密钥
// 通过签名-验证-计时推测密钥字节
void brute_force_pac_byte(int target_key_index) {
    for (int guess = 0; guess < 256; guess++) {
        // 1. 创建带猜测 PAC 的指针
        // 2. 触发 AUTIA 指令
        // 3. 测量执行时间（密钥匹配时更快）
        if (signature_verify_timing(guess) < threshold) {
            report_key_byte(target_key_index, guess);
        }
    }
}

缓解：现代处理器在 AUTI 指令设计中加入恒定时间保证，确保无论密钥是否匹配，指令耗时一致。

6.2 指针重用与签名爆破

8-bit PAC 的理论强度有限（2^8 = 256）。攻击思路：

1. 在线爆破：如果攻击者能触发大量 AUTIA 调用，可以暴力爆破 PAC 值。执行环境需提供持续的签名尝试机会。
2. 签名重用：如果同一指针的签名在不同上下文中有效（salt 固定或可预测），可被重放。

缓解措施： - 增加 TCR_EL1 中的 PACI (pointer authentication intensity) 位 - 确保每次签名使用随机 salt（SP 天然提供熵）

6.3 调试与异常处理挑战

PAC 对调试器提出新要求：

• LLDB/GDB：剥离 XPAC 才能显示真实地址
• 崩溃报告：需要识别 BRK #0x400 (PAC 认证失败) vs BRK #0x401 (BTI 检查失败)
• JIT 编译：动态代码需正确管理 PAC 上下文

七、前沿进展与生态展望

7.1 ARMv9.4 PAC 增强

ARMv9.4 引入的 FEAT_PAuth2 提供： - 双密钥 PAC：同一指针可同时承载两个独立签名，防御密钥泄露的双重保障 - 增强抗暴力破解：内部迭代次数提升，增加在线爆破难度

7.2 与 MTE (Memory Tagging Extension) 协同

PAC/BTE 解决的是控制流完整性 (CFI) 问题，MTE 解决的是内存安全性（空间/时间安全）问题。两者形成纵深防御：

┌─────────────────────────────────────────┐
│  攻击 : 写入越界损坏返回地址     │
│  防御 : MTE 检测写入越界 → 第一道防线     │
├─────────────────────────────────────────┤
│  攻击 : 通过堆喷射篡改函数指针   │
│  防御 : PAC 签名验证 → 第二道防线         │
├─────────────────────────────────────────┤
│  攻击 : 篡改 vptr 导致虚函数劫持 │
│  防御 : PAC + CFI 双重验证 → 第三道防线   │
├─────────────────────────────────────────┤
│  攻击 : JOP gadget 链构造        │
│  防御 : BTI 着陆点校验 → 第四道防线       │
└─────────────────────────────────────────┘

7.3 部署成熟度与建议

2024 年部署现状：

• Apple 生态：arm64e 完全强制，PAC+BTI 覆盖率 100%
• Android：内核强制 PAC，用户态逐步启用
• Linux：
• Ubuntu 24.04 / Debian 12：默认开启 PAC+BTI
• RHEL 9：内核 PAC 默认启用
• 关键服务器/容器场景建议启用 data-pointer PAC
• 开发建议：
• 新项目直接 -mbranch-protection=standard
• 敏感包装库（加密、认证、反欺诈）优先考虑数据指针 PAC
• JIT 引擎需特别处理 PAC 上下文

八、结语

ARM PAC 和 BTI 代表了硬件安全设计哲学的根本转变：从"发现漏洞-发布补丁"的反应式循环，到"在架构层面预防漏洞利用"的主动防御。它们不是银弹——复杂的侧信道攻击和硬件级弱点依然存在——但这确实是十年来硬件安全最重要的进步之一。

对于生产环境中的安全关键系统，现在是时候认真评估并部署 PAC+BTI 了。编译器的支持已经成熟，性能开销微乎其微，而安全收益是实实在在的：让攻击者的 ROP/JOP 武器库批量失效，将控制流劫持从"已知可行"变为"需要破解密码学签名"。

在内存安全与漏洞利用的永恒攻防中，PAC/BTI 让防守方第一次在硬件层面获得了非对称优势。

---

关键词：ARM PAC, Pointer Authentication, BTI, Branch Target Identification, 内存安全, ROP, JOP, CFI, Linux内核安全, arm64e