ARM Total Compute平台RSS安全启动机制解析

1. ARM Total Compute平台RSS固件启动机制解析

在嵌入式安全领域，ARM Total Compute平台的RSS（Root of Trust Secure Subsystem）架构提供了一套完整的硬件级信任根解决方案。作为安全启动的核心组件，RSS固件的启动流程设计直接影响整个系统的可信执行环境（TEE）建立。与传统的单阶段启动加载器不同，RSS采用分层验证的启动链设计，通过BL1和BL2的协同工作实现逐级安全验证。

1.1 RSS启动流程整体架构

RSS启动流程根据设备生命周期状态分为两个主要阶段：

• Provisioning Booting：发生在设备制造阶段，包括CM（Chip Manufacturer）和DM（Device Manufacturer）两个子阶段
• Normal Booting：设备出厂后的常规启动流程

这种分离设计实现了安全密钥与配置信息的分阶段注入，确保芯片制造商和设备制造商各自的安全资产相互隔离。在实际工程中，我曾遇到过因混淆这两个阶段导致的启动失败案例——某次在产线测试时误将DM阶段的供应包用于CM阶段，导致OTP编程失败。

1.2 关键组件交互关系

RSS启动过程涉及多个关键组件的协同工作：

code复制┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│    BL1_1    │───▶│    BL1_2    │───▶│     BL2     │
└─────────────┘    └─────────────┘    └─────────────┘
     ▲                   ▲                   ▲
     │                   │                   │
┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│   ROM固件   │    │    OTP      │    │    FIP      │
└─────────────┘    └─────────────┘    └─────────────┘

2. BL1启动流程深度剖析

2.1 BL1双阶段设计原理

BL1采用独特的双阶段设计，这种架构在安全性和灵活性之间取得了平衡：

BL1_1（ROM固件）特点：

• 固化在芯片ROM中不可修改
• 代码体积严格受限（通常<32KB）
• 仅实现最基础的密码学操作
• 负责BL1_2的初始验证和加载

BL1_2（OTP可编程）特点：

• 通过CM供应包写入OTP
• 支持算法升级和策略调整
• 实现完整的FIP解析和BL2验证
• 包含设备特定的安全策略

在调试某款车规级MCU时，我们发现BL1_2的OTP编程时序非常关键。过早触发编程会导致校验失败，建议在芯片上电稳定后延迟至少100ms再开始OTP操作。

2.2 BL1正常启动流程详解

2.2.1 BL1_1执行流程

1. 硬件复位后从ROM_BASE_S(0x11000000)启动
2. 初始化最小化安全环境（关闭中断、清空缓存等）
3. 从OTP读取BL1_2镜像和哈希值
4. 验证BL1_2完整性（SHA-256比对）
5. 将BL1_2加载到BL1_2_CODE_START指定地址
6. 跳转到BL1_2执行

关键调试技巧：当BL1_1卡在验证阶段时，可通过测量电源纹波和时钟稳定性来排除硬件问题。我们曾遇到因LDO输出不稳导致哈希校验随机失败的情况。

2.2.2 BL1_2核心功能实现

BL1_2作为承上启下的关键组件，主要完成以下任务：

FIP解析过程：

c复制// 典型FIP头部结构
typedef struct {
    uint8_t uuid[16];      // 镜像UUID
    uint64_t offset;       // 在FIP中的偏移量
    uint64_t size;         // 镜像大小
    uint32_t flags;        // 属性标志
    uint32_t reserved;
} fip_toc_entry_t;

BL2加载示例代码：

c复制// 从FIP中提取BL2镜像
int load_bl2_from_fip(void *fip_base, void **bl2_out, size_t *size_out) {
    fip_toc_entry_t *toc = (fip_toc_entry_t *)(fip_base + FIP_TOC_OFFSET);
    for (int i = 0; i < MAX_TOC_ENTRIES; i++) {
        if (memcmp(toc[i].uuid, BL2_UUID, 16) == 0) {
            *bl2_out = fip_base + toc[i].offset;
            *size_out = toc[i].size;
            return 0;
        }
    }
    return -1; // BL2 not found
}

安全验证关键步骤：

1. 使用PLAT_OTP_ID_BL1_ROTPK_0验证镜像签名
2. 检查安全计数器（PLAT_OTP_ID_NV_COUNTER_BL1_0）
3. 使用PLAT_OTP_ID_KEY_BL2_ENCRYPTION解密BL2
4. 将解密后的BL2拷贝到BL2_IMAGE_START

实践提示：BL1_2的调试符号加载地址必须与链接脚本中的定义完全一致。常见错误是忽略BL1_2_CODE_START的偏移量配置，导致调试器无法正确解析符号。

2.3 供应启动流程（Provisioning Boot）

2.3.1 CM供应阶段关键操作

CM供应包（encrypted_cm_provisioning_bundle_0.bin）包含芯片制造商的核心安全资产：

c复制struct cm_provisioning_data {
    uint8_t bl1_2_image_hash[32];  // BL1_2镜像哈希
    uint8_t bl1_2_image[BL1_2_CODE_SIZE]; // BL1_2完整镜像
    uint32_t rss_id;               // 芯片唯一标识
    uint8_t guk[32];               // 全局唯一密钥
    uint32_t cca_system_properties; // 系统属性位图
};

供应包通过以下命令加载到FVP：

bash复制--data css.rss.sram0=output/deploy/tc2/rss_encrypted_cm_provisioning_bundle_0.bin@0x0

2.3.2 DM供应阶段配置要点

DM供应包（encrypted_dm_provisioning_bundle.bin）包含设备制造商的安全配置：

c复制struct dm_provisioning_data {
    uint8_t bl1_rotpk_0[56];        // BL1根公钥
    uint8_t bl2_encryption_key[32]; // BL2加密密钥
    uint8_t bl2_rotpk_0[32];        // BL2根公钥哈希
    // ...其他安全资产
};

加载参数示例：

bash复制--data css.rss.sram1=output/deploy/tc2/rss_encrypted_dm_provisioning_bundle.bin@0x80000

供应阶段调试经验：

1. 供应包必须使用正确的magic number（CM为0xC0DEFEED，DM为0xBEEFFEED）
2. SRAM加载地址错误会导致BL1_1无法定位供应包
3. 建议在量产前验证OTP编程电压和脉冲宽度参数

3. BL2安全启动实现细节

3.1 MCUboot集成与定制

RSS选择MCUboot作为BL2的实现基础，主要考虑到：

• 成熟的A/B镜像更新机制
• 支持多种密码算法（RSA-3072/ECDSA-P256）
• 可扩展的安全计数器管理
• 丰富的硬件适配层接口

关键目录结构：

code复制mcuboot-src/
├── boot/              # 核心启动逻辑
├── docs/              # 设计文档
├── scripts/           # 镜像处理工具
└── sim/               # 模拟器支持

3.2 固件镜像打包与签名

3.2.1 镜像签名流程

使用imgtool进行签名的典型命令：

bash复制python3 imgtool.py sign \
    --key ${MCUBOOT_KEY_S} \
    --align 8 \
    --header-size 1024 \
    --version 1.2.0 \
    --security-counter 5 \
    bl2.bin bl2_signed.bin

签名布局文件示例（signing_layout_s.c）：

c复制enum image_attributes {
    RE_SECURE_IMAGE_OFFSET = 0x00010000,
    RE_SECURE_IMAGE_MAX_SIZE = 0x000F0000,
    RE_IMAGE_LOAD_ADDRESS = 0x71000000,
    RE_SIGN_BIN_SIZE = 0x00100000
};

3.2.2 FIP打包技巧

使用fiptool更新FIP的典型操作：

bash复制fiptool update \
    --align 8192 \
    --rss-bl2 bl2_signed.bin \
    --rss-scp-bl1 scp_romfw_signed.bin \
    fip.bin

经验分享：FIP中各个镜像的对齐参数直接影响加载性能。我们发现8KB对齐相比默认的4KB对齐能减少约15%的加载时间，特别是在eMMC存储介质上效果更明显。

3.3 多核启动协同机制

3.3.1 SCP启动流程

1. BL2通过ATU将SCP固件映射到0x71000000
2. 设置RSS_SYSCTRL->GRETREG唤醒SCP
3. 通过MHUv2等待SCP启动完成信号

c复制// 等待SCP启动完成的典型代码
while (channel_stat == 0) {
    mhu_v2_x_channel_receive(&MHU_SCP_TO_RSS_DEV, 0, &channel_stat);
}

3.3.2 AP启动控制

1. BL2验证AP_BL1镜像签名
2. 通过MHUv2通知SCP启动AP
3. SCP配置电源管理单元(PMU)上电AP核心

c复制mhu_v2_x_initiate_transfer(&MHU_RSS_TO_SCP_DEV);
mhu_v2_x_channel_send(&MHU_RSS_TO_SCP_DEV, 0, 1); // Slot 0用于启动命令

调试技巧： 当AP无法启动时，建议按以下顺序排查：

1. 检查AP_BL1的加载地址是否正确（应与AP的ROM基地址匹配）
2. 验证MHU通道是否初始化成功
3. 测量AP核心供电电压时序
4. 检查SCP日志中的错误代码

4. 实战调试技巧与问题排查

4.1 Arm DS调试配置

4.1.1 符号文件加载配置

4.1.2 常用调试断点设置

1. BL1_1入口点：bl1_1_entry()
2. BL1_2验证函数：validate_image_at_addr()
3. BL2镜像加载点：boot_load_image()

4.2 典型问题排查指南

4.2.1 启动卡住问题分析

mermaid复制graph TD
    A[启动卡住] --> B{卡在哪个阶段?}
    B -->|BL1_1| C[检查ROM固件哈希]
    B -->|BL1_2| D[验证FIP完整性]
    B -->|BL2| E[检查MCUboot日志]
    C --> F[测量电源/时钟]
    D --> G[确认OTP编程正确]
    E --> H[验证签名密钥]

4.2.2 常见错误代码处理

4.3 性能优化实践

4.3.1 启动时间优化

1. 并行验证：在BL1_2阶段同时进行解密和哈希计算
2. 缓存预热：提前加载后续阶段代码到缓存
3. 关键路径分析：使用ETM跟踪耗时最长的函数

4.3.2 安全加固建议

1. 启用PUF（物理不可克隆函数）保护根密钥
2. 实现运行时完整性度量（RIM）
3. 配置安全看门狗防止时序攻击

在某个智能电表项目中，我们通过优化BL2的验证逻辑（将RSA验证改为预计算哈希比对），使启动时间从1.2秒缩短到780毫秒，同时保持了同等安全级别。