ARM TrustZone与Microchip SAM L11安全开发实战

1. ARM TrustZone技术概述

TrustZone是ARM架构中实现硬件级安全隔离的核心技术，特别针对ARMv8-M架构的嵌入式系统进行了优化。这项技术通过在处理器层面建立安全状态和非安全状态，为嵌入式设备提供了硬件级别的安全防护机制。

1.1 TrustZone基本工作原理

TrustZone将系统资源划分为安全域(Secure Domain)和非安全域(Non-secure Domain)两个独立的世界：

• 安全域：可以访问所有系统资源，包括安全内存、非安全内存和安全外设。通常用于运行安全关键代码，如加密算法、安全启动、密钥管理等。
• 非安全域：只能访问非安全内存和非安全外设。用于运行常规应用程序代码。

状态切换通过专用的硬件机制实现，确保安全域和非安全域之间的隔离性。当处理器处于安全状态时，可以访问所有资源；处于非安全状态时，任何尝试访问安全资源的操作都会触发安全错误。

1.2 ARMv8-M架构的TrustZone实现

ARMv8-M架构对TrustZone进行了专门优化，使其更适合资源受限的嵌入式设备：

• 低延迟中断处理：安全和非安全中断都能得到快速响应
• 最小化开销：状态切换仅需几个时钟周期
• 专用指令支持：SG(Secure Gateway)指令用于安全函数调用
• 内存保护单元(MPU)增强：支持安全和非安全区域的独立配置

提示：与ARMv7-A的TrustZone实现不同，ARMv8-M的TrustZone设计更注重低功耗和实时性，特别适合物联网和边缘计算设备。

2. Microchip SAM L11安全特性

2.1 硬件架构概述

SAM L11系列微控制器基于ARM Cortex-M23核心，主频可达32MHz，集成了丰富的安全特性：

• TrustZone for ARMv8-M：硬件级安全隔离
• 加密模块：支持AES-128/256、GCM、SHA-1/256等算法
• 安全启动：基于硬件的信任根
• 防篡改检测：实时监控物理攻击
• 安全密钥存储：密钥永不暴露在非安全域

2.2 安全存储架构

SAM L11的存储器系统通过IDAU(Implementation Defined Attribution Unit)实现安全分区：

2.3 外设安全控制

每个外设通过PAC(Peripheral Access Controller)独立配置安全属性：

c复制// 示例：在MDK中配置USART0为安全外设
PAC->PER_REG[USART0_PAC_INDEX].PER = PAC_SECURE;

关键外设安全策略建议：

• 加密引擎：必须设为安全
• RTC：建议设为安全
• GPIO：可按引脚分组配置
• DMA：根据通道用途配置

3. MDK开发环境配置

3.1 软件准备

开发SAM L11 TrustZone应用需要以下组件：

1. MDK开发工具：

   • 基础版(MDK-Essential)：仅支持非安全开发
   • 专业版(MDK-Professional)：支持安全和非安全开发

2. 软件包：

   • ARM.CMSIS.5.0.1.pack或更高版本
   • Keil.SAML11_DFP-1.0.81或更高版本设备支持包

3. 编译器：

   • ARM Compiler 6（Cortex-M23仅支持AC6）

3.2 多项目工作区设置

TrustZone开发需要同时创建安全和非安全两个项目：

code复制NoRTOS.uvmpw (工作区)
├── sApp (安全项目)
│   ├── sApp.sct (分散加载文件)
│   ├── DebugConfig (调试配置)
│   └── interface.c (安全接口)
└── nsApp (非安全项目)
    ├── nsApp.sct
    └── main_ns.c

关键配置步骤：

1. 创建工作区并添加两个项目
2. 设置项目依赖关系：nsApp依赖sApp生成的接口库
3. 配置批量构建顺序：先构建sApp，再构建nsApp

3.3 调试配置

通过.dbgconf文件配置设备安全参数：

xml复制<DebugConfiguration>
  <DebuggerSetup>
    <ChipErase>CE2</ChipErase>
    <ChipEraseKey1>0xFFFFFFFF</ChipEraseKey1>
    <ChipEraseKey2>0xFFFFFFFF</ChipEraseKey2>
  </DebuggerSetup>
  <DeviceSetup>
    <DebugAccessLevel>DAL2</DebugAccessLevel>
    <ProgramUROW>1</ProgramUROW>
    <FlashSecureSize>0x8000</FlashSecureSize> <!-- 32KB安全Flash -->
    <FlashNSCSize>0x190</FlashNSCSize>       <!-- 400B NSC区域 -->
  </DeviceSetup>
</DebugConfiguration>

4. 安全项目开发实践

4.1 安全启动流程

安全项目的启动代码需要完成以下关键任务：

1. 初始化安全栈指针
2. 配置IDAU和SAU(如果支持)
3. 设置外设安全属性(PAC)
4. 初始化安全系统服务
5. 跳转到非安全代码

c复制void Secure_Init(void)
{
    // 1. 配置内存保护
    SCB_NS->VTOR = NS_APP_START;  // 设置非安全向量表
    
    // 2. 配置外设安全属性
    PAC->PER_REG[USART0_INDEX].PER = PAC_SECURE;
    
    // 3. 初始化安全服务
    Crypto_Init();
    
    // 4. 切换到非安全状态
    __TZ_set_MSP_NS(__initial_sp_ns);
    __TZ_set_CONTROL_NS(0);
    __TZ_set_PSP_NS(0);
    __asm volatile("bxns %0" : : "r" (NS_APP_START));
}

4.2 安全接口设计

安全域暴露给非安全域的接口需要特殊处理：

1. 将接口函数放在NSC(Non-Secure Callable)区域
2. 使用__attribute__((cmse_nonsecure_entry))标记
3. 对指针参数使用cmse_check_pointed_object()进行安全检查

c复制// interface.c - 放置在NSC区域
#include <arm_cmse.h>

int32_t __attribute__((cmse_nonsecure_entry)) secure_func1(int32_t x)
{
    // 安全检查示例
    if(!cmse_check_pointed_object(&x, CMSE_NONSECURE | CMSE_MPU_READ))
        return -1;
        
    return x * 2;  // 简单示例
}

4.3 分散加载文件配置

安全项目的sApp.sct文件需要明确定义各区域：

code复制LR_IROM1 0x00000000 0x00008000 {   ; 32KB安全Flash
  ER_IROM1 0x00000000 0x00007E00 { ; 主安全代码
   *.o (RESET, +First)
   *(+RO)
  }
  ER_IROM2 0x00007E00 0x00000200 { ; 400B NSC区域
   interface.o (+RO)
  }
}

RW_IRAM1 0x20000000 0x00002000 {   ; 8KB安全RAM
  .ANY (+RW +ZI)
}

5. 非安全项目开发

5.1 项目基础配置

在MDK中设置非安全项目：

1. 项目选项 → Target → Software Model → Non-Secure Mode
2. 设置正确的ROM/RAM地址范围
3. 包含安全项目生成的接口库(sApp_CMSE_Lib.o)

5.2 调用安全函数

非安全代码通过特定方式调用安全函数：

c复制// main_ns.c
#include "interface.h"  // 安全接口头文件

int main(void)
{
    int result = secure_func1(42);  // 调用安全函数
    while(1) {
        // 应用主循环
    }
}

5.3 内存管理注意事项

非安全代码必须遵守以下规则：

1. 不能直接访问安全内存地址
2. 所有对安全服务的请求必须通过NSC接口
3. 传递给安全函数的指针必须是非安全内存

c复制// 错误示例：尝试直接访问安全内存
volatile uint32_t *secure_var = (uint32_t*)0x20000000;
*secure_var = 42;  // 将触发安全错误

// 正确方式：通过安全接口访问
set_secure_variable(42);  // 由安全函数处理

6. 调试与测试

6.1 调试配置技巧

1. 混合调试：

   • 在sApp项目中配置Debug_all.ini脚本
   • 同时加载安全和非安全符号信息
   • 设置硬件断点时注意当前安全状态

2. 调试访问级别：

   • DAL2：完全访问（开发阶段）
   • DAL1：仅非安全访问（产品测试）
   • DAL0：仅BootROM访问（生产环境）

6.2 常见问题排查

1. 安全错误诊断：

   • 检查SCB->CFSR寄存器获取安全错误原因
   • 验证内存和外设的安全属性配置
   • 检查NSC区域是否正确定义

2. 函数调用问题：

   • 确保安全函数使用cmse_nonsecure_entry属性
   • 验证函数指针是否通过SG指令跳转
   • 检查NSC区域大小是否足够

3. 内存访问错误：

   • 确认指针参数已进行安全检查
   • 验证分散加载文件与硬件配置一致
   • 检查栈指针是否在正确安全区域

7. 生产部署考虑

7.1 安全固件更新

实现安全OTA更新的关键要素：

1. 使用安全启动验证镜像签名
2. 加密传输固件数据
3. 在安全环境中执行更新操作
4. 实现回滚保护机制

7.2 安全策略强化

产品化阶段建议：

1. 将调试级别从DAL2降为DAL1
2. 修改默认的芯片擦除密钥
3. 启用所有可用的防篡改检测
4. 锁定关键配置寄存器

c复制// 生产编程前配置
BOCOR->CEKEY1 = 0x12345678;  // 修改默认密钥
BOCOR->CEKEY2 = 0x9ABCDEF0;
UROW->SECURITY |= SECURITY_LOCK;

7.3 性能优化技巧

1. 最小化安全/非安全切换频率
2. 将频繁调用的安全函数组合成批处理API
3. 使用共享内存区域传递大数据
4. 优化NSC区域布局减少分支开销

在实际项目中，我们测量到典型的Secure-to-Non-secure调用开销约为20-30个时钟周期，而Non-secure-to-Secure调用约为50-60个周期。合理的设计应使跨域调用保持在最低必要水平。