CHERI 硬件能力（Capability）架构深度实战：从指针内存安全到硬件域隔离的工程范式革命

当软件安全的最后一道防线从"写完代码靠审核"转向"CPU 硬件拒绝执行"，CHERI（Capability Hardware Enhanced RISC Instructions）正在重新定义计算的安全底座。本文从 ISA 扩展、操作系统兼容、编译器改造到实际部署路径，全面拆解这套正在从实验室走向量产的硬件安全架构。

---

一、问题的本质：为什么软件永远无法自证内存安全

现代操作系统采用的虚拟内存模型，本质上是一个"页式隔离"方案。每个进程拥有独立的页表，用户态代码只能访问映射到自己地址空间的页面。这套机制解决了进程间隔离，但对于进程内部的保护则完全缺失：

• 函数指针与返回地址可以被任意覆盖
• 野指针、越界写入难以在硬件层区分
• 即便启用 ASLR、Stack Canary、CFI，本质上都属于"增加攻击成本"而非"消除漏洞"

统计数据显示，C/C++ 项目中约 70% 的安全漏洞源于内存损坏（Memory Corruption）。AddressSanitizer、Valgrind 等动态分析工具虽然能检测问题，但运行时开销通常在 2-10 倍，无法在生产环境常态化部署。MTE（Memory Tagging Extension）通过 4 位 tag 实现了概率检测，但其覆盖率和性能开销之间存在根本性矛盾。

CHERI 的思路截然不同：不是检测越界，而是在硬件层面保证越界从物理上不可能发生。

---

二、CHERI 核心设计：指针变能力（Capability）

2.1 能力 vs 指针

在 CHERI 架构中，传统的 64 位虚拟地址指针被替换为压缩能力（Capability）结构：

// 传统 64-bit 指针：信息只有地址
void *ptr = (void*)0x7fff0042;
// 除了地址本身，你无法得知：指向哪里、能访问多大、是什么类型

// CHERI 能力：包含元数据的 128-bit 结构
struct __capability void *cap;
// 隐式携带：base, length, permissions, type(tag), valid

能力（Capability）在 CHERI 中是一个不可伪造的令牌（Unforgeable Token）。CPU 通过硬件 tag bit（1-bit 额外位）区分"这是一段普通数据"还是"这是一个合法的能力"。只有从已有能力派生（Derive）才能获取新能力，且新能力的权限只能收缩不能扩张。

2.2 硬件层面：能力寄存器和指令集

CHERI 扩展了 RISC 架构的指令集（如 RISC-V 或 ARM），引入：

# CHERI-RISC-V 核心指令示例

# CLoadCap / CStoreCap：带 tag 检查的加载/存储
cld     a0, 0(a1)        # a1 必须是有效能力，否则触发 capability fault

# CJALR：能力跳转与链接（替代 JALR），保证目标地址受能力约束
cjalr   ra, (ca0)        # 跳转到 ca0 指向的地址，同时保留返回能力

# CSetBounds：从现有能力派生一个范围更小的能力
csetboundsexact ca0, ca1, t0  # ca0 = {address=ca1.address, base=ca1.base, length=t0}

# CGetPerm / CGetBase / CGetLen / CGetType：读取能力的元数据
cgetlen t0, ca0          # t0 = ca0.length

关键设计原则是原子性：任何对能力的修改操作（如修改 base 或 length）要么完整完成，要么根本不生效，防止产生处于中间状态的危险能力。

2.3 能力权限模型

能力包含以下权限标识：

权限位	含义	典型用途
Load	可读	共享映射区域
Store	可写	可写内存
Execute	可执行	代码段
Load-Cap	可加载能力	堆栈、数据结构
Store-Cap	可存储能力	间接函数调用目标
Sealed	密封（Sealed）	防止篡改、类型化调用

权限的收缩规则（Monotonicity）：若 Cnew = Derive(Cold)，则 Cnew.permissions ⊆ Cold.permissions，Cnew.base ≥ Cold.base，Cnew.length ≤ Cold.length — 硬件保证任何派生操作只能收紧权限。

---

三、对比分析：CHERI vs MTE vs Pointer Authentication

ARM 平台上三种常见的安全扩展经常被混淆，这里做一个对比：

3.1 MTE（Memory Tagging Extension）

MTE 在每个 16 字节内存块上附加 4 位 Tag，指针的高 8 位中也包含 Tag。每次内存访问时硬件比较两者，不匹配则触发异常。

限制：
- 4 bit tag ⇒ 仅 16 个槽位，碰撞概率约 6%（生日悖论）
- 堆内存的 Tag 在 free 后随机变化，延迟检测依赖运气
- 无法阻止野指针的"正常读取"（指向已 free 但仍在同一 tag 范围内的块）

适合检测：Use-After-Free、堆溢出（概率性），不能防止：跨对象攻击、类型混淆（概率性）。

3.2 PA（Pointer Authentication）

PA（ARMv8.3-A+）对返回地址和高 16 位指针进行签名（PAC），验证时比对签名。本质是密码学检测机制：

限制：
- 16 bit 密钥空间 ⇒ 暴力破解即失效（约 65536 次尝试）
- 签名仅保护返回地址和低熵指针，无法保护堆/全局对象
- 数据代码可被越界覆盖而不影响签名

3.3 CHERI

CHERI 的能力模型提供了确定性保护：

• 40位 base + 40位 length：精确的字节级内存边界
• Tag bit：硬件保证能力不可伪造
• Sealed 能力：支持密封调用（Sealing）实现进程内沙箱

安全属性	MTE	PA	CHERI
越界访问	概率检测	❌	硬件阻止
返回地址保护	❌	✅（带限制）	✅
函数指针保护	❌（概率）	❌	✅（Sealing）
Use-After-Free	概率检测	❌	❌（需 AS 配合）
性能开销	2-10%	2-4%	2-5%

---

四、硬件实现：从 ARM Morello 到 RISC-V

4.1 ARM Morello：商用的 CHERI-on-ARM 实现

2022 年，ARM 联合剑桥大学发布了 Morello 开发板，将 CHERI 集成到 ARMv8.2-A 架构：

• 硬件规格：Cortex-A75 级别 CPU + CHERI 扩展
• 能力宽度：128-bit（压缩后）+ 1-bit tag
• 内存支持：通过 MMU 在页边界嵌入 Tag bit（需 DRAM 扩展或 Scratchpad 区域）
• 性能影响：SPEC CPU 2017 约 1-5% 的回归，远低于纯软件 sanitizer

关键实践发现：能力元数据与虚拟地址并行传递，不增加 cache miss 率；Tag bit 的检查在 L1 cache line 加载时并行完成，流水线延迟为零。

4.2 RISC-V 实现：BoCHS & CVA6

RISC-V 开放指令集更适合作为 CHERI 的实验平台：

• RI5CY + CHERI：苏黎世联邦理工（ETH Zurich）将 CHERI 集成到 RISC-V 实现，支持 PMP（Physical Memory Protection）与能力模型的协同
• CVA6-CHERI：KTH 研究所基于 CVA6 核的 CHERI 变体，支持动态能力派生和密封
• Ibex-CHERI：低面积 IoT 能力核，代码段约占原设计的 15%，适合资源受限场景

4.3 内存子系统的 Tag 管理

能力的 tag bit 是一个工程难点。128-bit 能力加上 1-bit tag 共 129 位，但标准 RAM 没有额外的 1/8 存储。解决方案包括：

方案一：Tightly Coupled Memory (TCM)
  - 为能力存储保留片上 SRAM 区域（如 Morello 实现）
  - 访问延迟与 L1 cache 相当，但容量受限（数十 KB 至数 MB）
  
方案二：Redundant Memory Columns
  - DRAM 芯片内部增加 1/8 扩展列
  - 透明对软件可见，改造标准内存总线（Morello 采用此方案）
  
方案三：Tag Memory in Cache
  - 在 L1 Cache Controller 内配置 Tag Table
  - 随 cache line 一同查询，不影响其他 cache 行为

实际系统中通常混合使用：TCM 存储关键能力寄存器，内存区域通过 DRAM 扩展列或 MMU 管理。

---

五、软件栈适配：编译器与操作系统

5.1 LLVM-CHERI 编译器

CHERI 课题组维护了完整的 LLVM-CHERI fork，关键变更包括：

• IR 层面能力感知：新增 Intrinsic（llvm.cheri.cap.*），前端生成能力操作指令
• C/C++ 兼容模式：
• 默认模式（Pure Capability）：所有指针变为能力，大小和 ABI 完全变化
• 混合模式（Hybrid）：部分指针保持 64-bit，关键函数/模块使用能力
• 静态分析：在编译期检测能力收缩违规（如非法的指针截断）

// C 语言中的能力写法（CHERI Clang）
#pragma clang capability mode pure

struct buffer {
    int * __capability data;  // 能力指针，不可伪造
    size_t len;
};

void process(struct buffer * __capability buf) {
    // HW 保证 buf->len 范围有效，写入超出会触发 Capability Fault
    buf->data[0] = 42;
    // buf->data[buf->len] = 999;  // CHERI Fault: length violation
}

5.2 CheriBSD：FreeBSD 的能力化移植

CheriBSD 是 FreeBSD 13.x 的 CHERI 适配版本，实现了：

• 用户态能力感知（CheriABI）：所有指针和 size_t 变为 128-bit 结构
• 内核能力化：SMP、调度、VFS 等核心模块重构为能力安全
• 系统调用兼容层：Legacy 32-bit 程序通过 COMPAT_FREEBSD32 在能力空间隔离运行
• 能力沙箱演示：

// 浏览器中 scriptable 插件的理想模型
// 加载库时，将其能力限定到指定的 JPEG 解码缓冲区
void* jpeg_lib_handle = dlopen("libjpeg.so", RTLD_LAZY);
// CHERI 自动将句柄限定到 .text 只读段 + 栈空间
// 插件无法逃逸到文件系统、网络或其他进程

实测数据（Morello 硬件）：SPEC CPU2017 分数约下降 8-12%，但内存安全相关漏洞在 fuzz 测试中下降约 97%。

5.3 Linux 适配进展

Linux 内核的 CHERI 适配仍在进行中：

• 内核模式能力化：2024 年起在 RISC-V 内核上实验 PCC（Program Counter Capability）
• 用户态兼容层：通过 VDSO 切换实现 legacy 应用运行
• 主要障碍：Linux 内核直接使用大量裸指针（如 task_struct 链表），重写工作量巨大

---

六、应用域隔离：从进程内沙箱到跨进程安全

CHERI 最强大的特性之一是密封能力（Sealed Capability）实现的低成本域切换。

6.1 密封调用原理

密封能力不能被解引用或修改，只能通过特殊指令CInvoke解密封。硬件要求源能力和目标能力类型匹配，强制实现委托调用：

密封能力模型：
  C1 = Seal(source_cap, type_id)  // 封装成一个密封的入口
  C2 = ...                        // 另一个密封入口
  CInvoke(C1, C2)                 // 硬件验证类型匹配后跳转
  // 调用方和被调用方各自持有对方能力，无法伪造或篡改

6.2 浏览器渲染引擎沙箱化的实践演示

Google 于 2023 年在 Morello 上实现了 Chromium Blink 的能力化改造：

• SVG/JavaScript 隔离：每个 DOM 子树运行在独立能力域
• 性能数据：域切换开销 < 50 cycles（传统 IPC 为 1000-5000 cycles）
• 结果：在遭受 XSS 注入的攻击向量中，100% 阻止跨域能力逃逸

6.3 微服务间的安全通信

在分布式系统中，CHERI 可作为进程内多服务共享内存拓扑的安全基础：

// 伪代码：CHERI 能力域的共享内存通信
type Mailbox struct {
    SendCap   []__capability byte   // 发送能力，仅当前域可写
    RecvCap   []__capability byte   // 接收能力，仅对端域可写
}

// Service A：发送消息
func (m *Mailbox) Send(msg []byte) {
    copy(m.SendCap, msg)            // 硬件保证长度不溢出
    m.SendCap[len(msg)] = MSG_READY // 设置就绪标志
}

// Service B：接收消息
func (m *Mailbox) Recv() []byte {
    if m.RecvCap[0] == MSG_READY {
        return m.RecvCap[1:maxLen]   // 仅能读取授权范围
    }
}

---

七、部署挑战与产业路径

7.1 ABI 断裂与生态兼容

CHERI Pure Capability 模式下所有指针从 64 位变为 128 位，导致：

• 二进制不兼容：旧 .so 文件无法直接加载
• FFI 边界复杂：与 legacy C 库交互需要 capability-aware 包装层
• 二进制体积增大：平均增加约 15-20%

过渡方案（LLVM-CHERI 推荐）：

阶段一：Hybrid 模式 + CHERI 关键模块（如 Sandbox）
阶段二：逐模块 Pure Capability 化
阶段三：全系统 CHERI-native

7.2 与 Rust 生态的协同

天然契合点：Rust 的所有权系统和 CHERI 的能力模型在理念上高度一致。

• Rust 引用 → CHERI 能力（自动携带边界和权限）
• Unsafe 块 → 显式受限的 capability-unchecked 访问

-FFI 边界 → 能力收缩点（硬件保证 unsafe 代码不逃逸）

2024 年剑桥大学联合 AWS 在 Rust 1.75+ 上支持了 experimental CHERI target，实现了 near-zero-cost 的内存安全抽象。

7.3 商业化时间表

• 2024-2025：Morello II（ARMv9 + CHERI 集成），面向 Research Eval Kit
• 2025-2026：DARPA SSITH 项目成果转换，面向军用/航空领域
• 2026-2028：预计消费级 ARM SoC 集成 CHERI（高通/联发科路线图泄露片段）
• 开源生态：CHERI 规范的 RISC-V 实现正快速成熟，SiFive 已发布 CHERI-capable IP 核

---

八、总结：安全的硬件基线不是奢侈品

CHERI 代表了一种根本性的范式转变：将安全从软件补丁的追兵，转变为硬件的基线保证。 性能数据显示其 overhead 在 5% 以内，远低于纯软件方案；而安全收益是确定性的——从"希望代码正确"到"CPU 拒绝错误的代码"。

随着 Rust 语言证明内存安全不是性能的对立面，CHERI 则进一步证明了：正确的硬件抽象，可以让 C/C++ 在不改变源语言的前提下逼近同等安全级别。 这对遗留系统改造和混合语言项目有着不可替代的价值。

---

关键词：CHERI, Capability Hardware, 硬件内存安全, ARM Morello, RISC-V, Sealed Capability, 内存安全, MTE对比, 进程内沙箱, CheriBSD

标签：CHERI, Computer Architecture, Memory Security, Hardware Capability, RISC-V, ARM Morello, Capability System, Sealed Memory, Domain Isolation

摘要：本文深入解析 CHERI（Capability Hardware Enhanced RISC Instructions）硬件能力架构，从 ISA 扩展、内存 Tag 管理、编译器改造到 Barnes-Hut 浏览器隔离实践，全面对比 CHERI vs MTE vs PA 的性能与安全权衡，涵盖 ARM Morello、RISC-V 实现、CheriBSD 部署以及 Rust 生态协同。