ARM CCA 深度工程：Realm Management Engine 与机密计算硬件隔离架构全解析

ARM CCA（Confidential Compute Architecture）代表了机密计算从静态加密向运行时隔离的完整范式演进。本文深入剖析 CCA 的硬件隔离机制、RMM 固件设计、与 Intel TDX / AMD SEV-SNP 的架构对比，以及在云原生生产环境中的实际部署与限制。

问题空间：为何需要 CCA

2024 年至 2026 年间，机密计算（Confidential Computing）从"信任云服务提供商"演进为"不信任任何人，包括 hypervisor"的经典安全模型。传统 Trusted Execution Environment（如 TrustZone）仅提供单个安全世界（Secure World）与正常世界（Normal World）的二元分割，无法满足现代多租户云环境中虚拟化工作负载的动态隔离需求。

ARM CCA 的核心设计目标是在不依赖 Hypervisor 可信的前提下，为每个虚拟机工作负载建立独立的加密执行环境——称为 Realm：

• 内存隔离：Hypervisor 无法读取 Realm 内数据，即使宿主机被攻陷
• 动态认证：基于 DICE 硬件信任根，Realm 可通过远程认证（Remote Attestation）证明完整性
• 资源所有权反转：Realm 的内存分配和管理由 Realm 自身决定，Hypervisor 仅执行 Realm 的调度请求

2024 年下半年微软 Azure Cobalt 100 ARM 处理器（基于 Neoverse V2 + CCA）和 Google Axion 的规模部署，标志着 CCA 从理论设计走向生产环境。

架构全景：四个世界与 RMA

CCA architecture 将系统划分为四个执行世界（World）：

Realm 运行于 EL0（用户态）和 EL1（内核态），但物理地址空间的访问由 RME（Realm Management Engine） 硬件强制隔离。RME 是 CCA 的核心硬件组件，位于 CPU 内存子系统中，负责：

1. Granule Protection Table (GPT)：唯一的物理 page 所有权表
2. Realm Physical Address (RPA) 到 Physical Address (PA) 的加密映射
3. 拦截越权访问：当 Normal World 尝试访问 Realm 内存时，总线直接触发 fault

与 Intel TDX 的 SEAM（Secure Arbitration Mode）或 AMD 的 SEV-SNP VMSA（Virtual Machine Save Area）相比，CCA 的分层隔离更加明确：Root World 拥有绝对控制力，Hypervisor（Normal EL2）完全被排除在 Realm 之外。

Granule Protection Table：硬件级内存所有权

GPT 是 CCA 的硬件数据结构，维护在内存中并由硬件自动管理。每个 GPT entry（开销约 1GB 物理内存占用 64KB）记录每个物理 4KB page 的归属。

GPT entry 的三元组： - Granule State：Secure / NonSecure / Realm / Root（4 种状态，必须互斥） - Owner：指定 page 归属的 Realm（Realm Identifier） - Permissions：读/写/执行权限向量

当 DMA 设备或另一 PE（Processing Element）尝试访问某个 page 时， interconnect 中的 RME 拦截请求并检查 GPT。若访问者 World 与 page State 不匹配，直接触发 external abort——这比软件-based 安全方案（如 VT-d 重映射）具有更低的延迟和更强的安全边界。

Realm VM 视角的地址转换链：
VA (Realm VA) → GPA (Realm IPA) → RPA (Encrypted PA) → PA
      EL1 PTW        Stage-2 (Realm)        RME Bus       DRAM
                         (RMM控制)

关键设计细节：Stage-2 页表由 RMM（Realm Management Monitor） 维护，但 PTW（Page Table Walk）硬件行为由 RME 保证——这意味着 Realm 自己的 Stage-1 页表由 Realm OS 管理，Stage-2 由 RMM 管理而不经过 Hypervisor，这是 CCA 安全模型的根本保证。

RMM (Realm Management Monitor)：Realm 专用固件

RMM 是 CCA 架构中最精密的软件组件，运行于 Root EL2（最高权限，且对 Realm 不可见）。RMM 承担三个核心职责：

3.1 Realm 生命周期管理

RMM 通过为 Hypervisor 暴露的 RMI（Realm Management Interface） 实现 Realm 的创建、销毁、运行调度：

// 伪代码：RMI 调用流程（Hypervisor → RMM）
// 1. Hypervisor 调用 RMI_REALM_CREATE 创建 Realm
rmi_result = smc(RMI_REALM_CREATE, rmm_buffer, realm_params);

// 2. RMM 初始化 Realm 资源（GPT 分配、Realm 寄存器状态清零）
// 3. Hypervisor 通过 RMI_REALM_INIT 配置 Realm 的 RAM
// 4. Hypervisor 通过 RMI_REALM_ACTIVATE 激活 Realm 并进入执行

每个 Realm 有独立的寄存器上下文（Realm Context），保存于 Realm 私有的加密内存中。Realm Entry/Exit 时，RMM 负责：

• Entry：恢复 Realm 寄存器状态，切换至 Realm EL1，设置 RME GPT 状态
• Exit：保存 Realm 寄存器状态，切换至 Root EL2，设置 GPT 为 Normal

Context Switch 开销约为 1500-2500 个 CPU cycles，与 VM Exit（~1000 cycles）量级相当。

3.2 内存委派与撤销（Granule Delegation）

Realm 与 Hypervisor 之间的内存委托通过 RMI 的 Delegate/Undelegate 操作实现：

Realm 需要物理内存时：

Realm OS 调用 PSCI call → SMC 进入 RMM
RMM 从 Realm 私有池中分配 GPT entry
RMM 初始化物理 page（清零 + 设置 Realm 加密标签）
RMM 返回 Realm 可用的物理地址

Realm 归还内存时：

Realm OS 指定 GPA range
RMM 解密并清零对应 page（安全清除，防止内存残留泄露）
RMM GPT 将 page 状态改为 Normal
RMM 通知 Hypervisor 该内存可用

此过程保证 Realm 归还的数据不会被残留攻击——RMM 始终以加密方式清理 page 内容。

3.3 vCPUs 与中断虚拟化

RMM 通过 RMI_VCPU_INIT 初始化 vCPU，并为每个 vCPU 维护独立的 realm_vcpu 结构体，包含：

• GPR（通用寄存器）与系统寄存器上下文
• 虚拟中断使能状态（与 GICv4 ITS 集成）
• Realm PSCI 回调（用于 Realm OS 休眠/唤醒）

中断传递路径：GIC → RMM（检查目标 Realm）→ Realm EL1（直接处理），Hypervisor 仅在 Realm Exit 时收到对应的 virtual interrupt 通知。

认证机制：DICE 与证书链

CCA 继承了 ARM 的 DICE（Device Identifier Composition Engine）标准，为 Realm 建立完整的信任链：

Root of Trust (硬件 PKA)
  ↓ DICE 证书
CCA Platform (EL3 Firmware + RMM)
  ↓ Realm Identity Key (RIK)
Realm Initial Measurement (Realm 初始测量值)
  ↓ Realm ACID (Attestation Certificate ID)
Realm 运行时报告（包含 HW measurement + RMM measurement + Kernel/Initrd hash）
  ↓
Remote Attestation Token → 远程验证方

与 Intel TDX Quote 相比，CCA 的 Realm 认证报告有以下显著差异：

1. 双层测量：CCA 对 RMM 本身和 Realm 内容分别签名，便于独立审计
2. 递进式认证：Realm 可动态追加组件测量（如后续加载的 kernel module），证书链在已有基础上扩展
3. 轻量级 Token：CCA Realm Token 约 2KB，而 TDX Quote 通常 4-8KB（取决于 PCK 证书链）

实际部署中，云平台可提供 RMM 参考实现 + 校准测量值，使租户可验证 Realm 运行的是经过审计的标准固件。

与 Intel TDX / AMD SEV-SNP 工程对比

关键架构差异：CCA 将 RMM 与 Hypervisor 的接口明确为 RMI（单向委托式 API），而不是双向事件通道（如 AMD 的 GHCB），这减少了Hypervisor攻击面但牺牲了灵活性。Intel TDX 的 SEAM 与 DMC（Trust Domain Module）之间也存在类似约束。

Linux CCA 内核支持

Linux 5.19 引入 CCA 基础支持，6.x 系列持续完善。核心实现位于：

• RMM 侧：ARM 开源 RMM（https://github.com/sofa/sofa，后演进为 tf-rmm）
• KVM 侧：arch/arm64/kvm/cca.c，实现 KVM 到 RMI 的桥梁
• Realm VM 内核：标准 Linux 内核运行在 Realm EL1，通过 kvm-arm 精简版接入

Realm 内核与运行于 Normal EL2 的 Hypervisor 通信的唯一通道是 RMM 代理的 PRI（Protocol Request Interface）：

// Realm 内核调用流程（示例）
realm_call(KVM_HC_HOST_HANDLE, &req)    // KVM 模拟 HVC
   ↓
SMC 进入 Root EL2 (RMM)                  // 硬件陷入 RMM
   ↓
RMM 解析 KVM 请求，限权执行
   ↓
回调至 Hypervisor (通过 RMI)             // Hypervisor 处理物理资源
   ↓
结果经 RMM 返回 Realm 内核               // 安全通道返回

性能开销基准

基于 2024 下半年 Azure Cobalt 100 / Google Axion 环境的测试数据（非官方，来自第三方评测）：

观察： - CCA 在计算密集场景（推理/数据分析）开销极低（3-5%） - IO 与内存密集型场景的额外成本主要来自 RME GPT 检查（与加密开销无关） - 多 Realm 并发时的 GPT 竞争可通过 RMM 大页（如 2MB）转 Stage-2 优化

工程实践中的关键挑战

5.1 内存热插拔限制

Realm 不支持运行时动态添加物理内存（由 Hypervisor 处理的 delegate 路径异步引入延迟）。生产环境下建议一次性分配充足内存或设计应用支持 Realm 内的内存超额分配 + swap。

5.2 vCPU 扩展性

CCA 当前规范单 Realm 最多 16 个 vCPU。对于需要大量并行核心的 HPC/AI 训练场景，需要多 Realm 联合部署，引入跨 Realm 通信开销。

5.3 设备直通（IO 路径）

Realm 使用 VirtIO 半虚拟化设备网络/存储（通过 Hypervisor），加密流量需要额外的 Realm IO（RIOT）支持。当前 CCA 生产环境对 GPU/FPGA 加速器的直通支持极为有限，主要依赖 Normal VM 作为代理中转。

5.4 调试与可观测性

Realm 内运行 eBPF 或 perf 工具需要 RMM 显式暴露 PMU（Performance Monitoring Unit）寄存器权限。Realm 被设计为对 Hypervisor 完全"黑箱化"，排障手段远少于常规 VM。

未来演进方向

1. Realm Management Module (RMM) 标准化：2025-2026 年 ARM 计划发布 RMM 公开规范，使第三方（如 Linux 社区/云厂商）可编写替代 RMM，避免单一供应商锁定。

2. 与 RAS 协同：ARMv9.5 将 RAS（Reliability, Availability, Serviceability）扩展引入 Realm，使 Realm 可自主响应硬件错误（如 ECC 纠正、page retire），无需 Hypervisor 干预。

3. 跨 Realm 安全共享：Realm Granule Sharing 机制允许两个 Realm 在受控条件下共享内存页（通过 RPT 映射），为多租户可信服务链（如 Agent 与 Model Provider）提供安全数据交换通道。

4. CCA + 机密 AI 推理：Azure Confidential AI 项目已展示在 CCA Realm 中运行 PyTorch/ONNX Runtime，实现端到端加密推理——请求输入、模型权重、推理结果全程不暴露给 Hypervisor。

结语

ARM CCA 是当前最具野心的硬件隔离架构之一，其硬件级 GPT 内存所有权 + RME 总线拦截 + DICE 认证的工程组合，为云原生工作负载提供了远超软件沙箱的安全边界。尽管生态成熟度仍落后于 SEV-SNP（在部署规模上）和 TDX（在 Intel 生态整合上），但 CCA 的模块化设计（RMM 可插拔、RMI 单向委托、Realm 与 Normal 严格分离）为长期演进留下了充足空间。

对于构建"零信任"云原生基础设施的团队，CCA 值得深入评估——尤其在面临数据驻留（Data Residency）、跨组织协作计算、敏感 AI 模型保护等场景时，CCA 提供了传统方案无法比拟的信任锚点。