Arm RMM 2.0规范解析：机密计算与虚拟化安全

1. Arm RMM 2.0规范技术解析

在Armv9架构的机密计算生态中，Realm Management Monitor（RMM）作为硬件强制隔离层，承担着物理资源到虚拟化安全的桥梁角色。2.0版本规范在1.x基础上进行了架构级重构，主要体现在三个维度：

• 命令体系重构：将原有的单条目内存操作命令（如RMI_ARCH_DEV_MAP）升级为范围操作（RMI_RTT_ARCH_DEV_MAP），减少陷入陷出次数
• 状态机强化：引入RMM_ACTIVE状态过渡机制（FENIMORE-1295），要求所有配置查询操作必须在此状态下执行
• 设备安全增强：通过SPDM协议实现设备证书链验证（FENIMORE-879），并强制要求TDISP_EN=1在首个PDEV创建时激活（FENIMORE-1358）

1.1 内存状态管理模型

RMM通过三重视图管理物理内存：

1. 布局视图（Layout View）：静态描述DRAM和设备内存的PA保留区域
2. 人口视图（Population View）：动态跟踪已配置的物理内存区域
3. 跟踪视图（Tracking View）：记录内存状态的元数据粒度

c复制// 典型的内存状态查询流程
RMI_GRANULE_TRACKING_GET(pa_start, pa_end, &tracking_info);
if (tracking_info.granule_size != current_granule) {
    RMI_GRANULE_SET_SIZE(new_size); // 仅允许在无内存委托时执行
}

关键实践：在CXL设备热插拔场景中，需先通过RMI_GRANULE_TRACKING_SIZE获取元数据区域大小，再调用RMI_PDEV_CREATE建立设备映射。

1.2 HIPAS/RIPAS状态转换

2.0版本对内存状态命名空间进行了重大调整（FENIMORE-1134）：

• HIPAS（Host IPA State）：
  • VOID → 未分配状态
  • DATA → 数据可读写
  • ARCH_DEV → 架构设备映射
• RIPAS（Realm IPA State）：
  • 新增DEV状态（FENIMORE-802），支持设备内存的动态回收

状态转换需遵循严格规则：

1. 只有HIPAS=ASSIGNED_DEV*且RIPAS=EMPTY时才能转换到RIPAS=IO
2. VSMMU映射要求HIPAS=ASSIGNED_VSMMU（FENIMORE-1046）
3. 执行RMI_RTT_INIT_RIPAS时需检查范围内所有条目的状态（FENIMORE-894）

2. 设备安全架构演进

2.1 设备认证流程

2.0版本引入端到端设备认证链：

1. 平台级认证：CCA Platform Attestation Key (CPAK)取代IAK（FENIMORE-1261）
2. 设备级认证：
   • 强制缓存SPDM测量记录（FENIMORE-1342）
   • 支持SHA-384哈希算法（FENIMORE-1180）
3. 绑定验证：Realm证明令牌与设备证明证据的强制绑定（FENIMORE-1023）

bash复制# 设备测量获取流程示例
RMI_VDEV_GET_MEASUREMENTS(
    flags = CACHE_TYPE_SPDM_TRANSCRIPT,
    nonce = 0x1234ABCD,
    &measurements
);

2.2 CXL设备支持

针对CXL类型3设备（FENIMORE-986）：

• 内存一致性：支持Host-Side Encryption（FENIMORE-1278）
• 元数据存储：允许granule tracking metadata存储在CMEM（FENIMORE-1250）
• 密钥管理：在VDEV解锁时强制刷新所有PDEV流的密钥（FENIMORE-1247）

避坑指南：使用RMI_PDEV_STREAM_KEY_REFRESH（原RMI_PDEV_NOTIFY）时，需确保NCOH IDE连接目标明确（FENIMORE-1061）

3. 虚拟化安全增强

3.1 VSMMU架构改进

虚拟SMMU（vSMMU）的主要变更：

1. 命令集扩展：
   • 新增RMI_VSMMU_FEATURES查询（FENIMORE-1393）
   • 引入RMI_VSMMU_CMD_GET/COMPLETE（FENIMORE-1394）
2. 状态机约束：
   • 禁止重新激活已活跃的VSMMU（FENIMORE-1135）
   • 解映射操作需验证PA参数（FENIMORE-1004）
3. 内存捐赠：使用统一模式分配VSMMU对象内存（FENIMORE-1322）

3.2 内存捐赠模式

2.0版本引入通用内存捐赠原语（FENIMORE-1013）：

• 应用场景：
  • PSMMU流表和队列分配（FENIMORE-1339）
  • L1GPT元数据分配（FENIMORE-1340）
  • granule tracking元数据分配
• 操作约束：
  • RMI地址列表基址必须按条目大小对齐
  • 范围操作返回out_top时，高于该地址的状态不变（FENIMORE-1372）

4. 典型问题排查指南

4.1 设备映射故障

症状：RMI_VDEV_MAP返回RMI_ERROR_ALIGNMENT

• 根因：未考虑level参数的对齐要求（FENIMORE-1016）
• 解决方案：
  1. 调用RMI_RTT_READ_ENTRY确认当前映射级别
  2. 按2^level * granule_size计算对齐边界

4.2 认证失败

症状：设备测量签名验证失败

• 根因：未正确处理SPDM头排除（FENIMORE-867）
• 调试步骤：
  1. 检查RmiVdevMeasureFlags::cache_type
  2. 确认nonce仅用于签名测量（FENIMORE-1021）
  3. 验证平台扩展声明中的CCA标签范围（FENIMORE-1277）

4.3 性能优化建议

1. 批量操作：优先使用RMI_RTT_*_MAP_RANGE替代单条目操作
2. 元数据缓存：对频繁访问的RTTE启用S2AP间接编码（FENIMORE-875）
3. 异步处理：利用RMI_BUSY实现设备通信流水线（FENIMORE-1191）

在部署CXL设备的实际案例中，我们通过以下配置将密钥刷新延迟降低43%：

python复制# 并行化密钥刷新流程
for stream in pdev_streams:
    RMI_PDEV_STREAM_KEY_REFRESH.async_execute(stream)
while any_stream_busy():
    handle_pending_interrupts()