Cortex-M33 硬件安全隔离（TrustZone）：原理、实现与应用

目录摘要1 引言2 TrustZone 的安全域架构2.1 双安全域模型2.2 硬件隔离资源3 内存与资源的安全归属机制3.1 安全归属单元SAU3.2 IDAU 与芯片级归属3.3 非安全可调用NSC区域4 安全状态切换与中断处理4.1 直接函数调用4.2 异常入口/返回的自动切换4.3 跨域中断的性能开销5 外设与存储的 TrustZone 保护5.1 GD32F527 的 TrustZone 保护控制器5.2 非法访问的处理策略5.3 安全启动与唯一启动入口6 TrustZone 的配置方法与应用策略6.1 基础配置流程6.2 安全启动策略选择6.3 安全域间通信优化6.4 应用注意事项7 结论摘要TrustZone 是 Armv8-M 架构引入 Cortex-M 系列的硬件安全隔离技术Cortex-M33 作为首批支持该架构的处理器之一将系统级安全从软件层面提升至硬件强制隔离层面。与 Cortex-M4 和 Cortex-M7 依赖 MPU 实现进程级隔离不同TrustZone 在 CPU 内部构建了安全Secure与非安全Non-secure两个硬件隔离的执行域通过安全归属单元SAU、安全/非安全双 MPU、堆栈限制寄存器等机制实现资源访问的硬件级管控。本文从安全域划分、内存归属机制、状态切换、外设保护及实测性能开销五个维度系统分析 Cortex-M33 TrustZone 的工作原理并结合 GD32F527 等实际芯片的实现方案给出配置方法与应用策略。研究表明TrustZone 的跨域中断切换仅引入约 32 周期的额外延迟安全世界代码增量可控制在 118 至 280 行在可接受的开销下实现了显著的安全隔离增益。关键词Cortex-M33TrustZone硬件安全隔离Armv8-MSAU安全启动1 引言嵌入式系统安全面临的核心矛盾在于传统的软件安全方案如加密库、安全启动代码运行在与非安全代码共享的同一执行环境中一旦攻击者利用软件漏洞获取执行权限安全机制本身即可被篡改或绕过。Cortex-M4 和 Cortex-M7 的 MPU 能够提供进程间内存隔离但其配置和策略完全由软件管理无法抵御具有特权级执行能力的攻击者。Armv8-M 架构引入的 TrustZone 技术从根本上改变了这一格局。Arm 官方将其定位为“通过内置在 CPU 中的硬件强制隔离将关键安全固件和私有信息如安全启动、固件更新和密钥与应用程序的其余部分隔离”。Cortex-M33 的 TrustZone 实现已通过EAL6通用标准认证适用于智能卡、SIM 卡和银行卡等高安全等级应用。本文旨在系统阐述 Cortex-M33 TrustZone 的硬件原理、资源配置方法及实际应用策略为基于 GD32F527 等 Cortex-M33 芯片的安全设计提供技术参考。2 TrustZone 的安全域架构2.1 双安全域模型TrustZone 将 Cortex-M33 的运行环境划分为两个硬件隔离的安全域安全域Secure State运行可信固件包括安全启动代码、密钥管理例程和加密操作。该域可访问所有内存和外设资源。非安全域Non-secure State运行常规应用代码。该域对标记为“安全”的资源访问将被硬件阻断。每个安全域内部又分为特权模式和非特权模式从而形成S/NS × 特权/非特权的四象限权限模型。2.2 硬件隔离资源TrustZone 为安全域提供了独立的硬件资源配置这些资源在非安全域中不可见或不可访问资源安全域非安全域MPU独立的安全 MPU独立的非安全 MPUSysTick独立的安全 SysTick独立的非安全 SysTick堆栈指针MSP_S / PSP_SMSP_NS / PSP_NS堆栈限制寄存器MSPLIM_S / PSPLIM_SMSPLIM_NS / PSPLIM_NS向量表偏移寄存器VTOR_SVTOR_NS这种“banked resources”设计意味着安全域的状态在非安全域中完全不可见安全固件的中断向量表、堆栈和 MPU 配置不会因非安全代码的错误操作而损坏。3 内存与资源的安全归属机制3.1 安全归属单元SAUSAU 是 Cortex-M33 中可编程的内存安全归属控制器最多支持8 个区域。每个 SAU 区域定义了地址范围及其安全属性安全S、非安全NS或非安全可调用NSC。SAU 的工作逻辑为当 CPU 发起内存访问时硬件将目标地址与 SAU 区域进行匹配确定该地址应归属的安全域。SAU 可设置为“全部非安全”ALLNS模式此时所有未被显式标记为安全的区域默认归属非安全域。3.2 IDAU 与芯片级归属除 SAU 外芯片厂商可定义实现定义归属单元IDAU提供硬件固定的安全归属映射。实际的安全归属由SAU 与 IDAU 共同决定当两者定义不一致时采用安全级别更高的归属S NSC NS。以 GD32W51x 为例其 IDAU 映射将 Flash、系统 SRAM 和外设空间双重映射为安全和非安全副本而外部存储器QSPI Flash/PSRAM则不进行双重映射。这种设计使同一物理资源在安全域和非安全域中呈现不同的地址视图。3.3 非安全可调用NSC区域NSC 区域是 TrustZone 的关键机制允许非安全代码通过安全网关Secure Gateway, SG指令跳转到安全域的函数入口。NSC 区域本身标记为非安全可访问但其中的代码执行SG指令后CPU 将切换到安全状态并跳转到真正的安全函数。这一设计使安全服务可以以受控方式暴露给非安全应用而无需共享安全域的完整执行环境。4 安全状态切换与中断处理4.1 直接函数调用TrustZone 支持安全域与非安全域之间的直接函数调用Arm 官方描述其具有“低延迟”特性。非安全代码通过 NSC 区域中的 veneer 函数调用安全服务安全代码执行完毕后通过BXNS指令返回非安全域。4.2 异常入口/返回的自动切换当异常发生时CPU 根据异常的目标安全状态自动完成状态切换。异常入口时安全数据在寄存器组中受到自动保护异常返回时自动恢复原安全状态。4.3 跨域中断的性能开销一项基于 Raspberry Pi Pico 2RP2350和 STM32L552 的实证研究测量了 TrustZone 跨域中断的实际开销安全域 SysTick 处理在 FreeRTOS 上平均消耗120 个 CPU 周期在 Zephyr 上消耗172 个周期。专用安全 SysTick 的跨域切换当安全域拥有独立的 SysTick 单元时每次到期都会触发安全/非安全域之间的 banked 中断切换平均引入约32 个周期的额外延迟。该研究表明TrustZone 的中断处理开销是小且可预测的不会对实时系统的确定性产生显著影响。5 外设与存储的 TrustZone 保护5.1 GD32F527 的 TrustZone 保护控制器以 GD32F527 为例其 TrustZone 保护控制器TZPCU包含三个子模块TZSPC安全特权控制器定义外设的安全属性和特权属性。对于安全属性可配置的外设TZSPC 中的寄存器决定其安全/特权状态。TZBMPC基于分块的存储保护控制器控制内部 SRAM 的分块安全归属。每个 SRAM 块的安全状态由 TZBMPC 中的寄存器定义。TZIAC非法访问控制器处理安全违规访问产生非法访问事件。此外AHB/APB 总线桥中嵌入了HTZPPC/PTZPPC 防火墙对安全/特权违规传输进行阻塞并产生非法访问事件。5.2 非法访问的处理策略GD32F527 对不同资源的非法访问采取差异化的处理策略外设寄存器的非法非安全访问非安全事务访问安全外设被阻塞产生非法访问事件但不产生总线错误。读操作返回 0写操作被忽略。内存的非法非安全访问非安全传输访问安全内存块被阻塞同时产生非法访问事件和总线错误。这一差异反映了安全设计的权衡外设访问的静默失败避免了非安全代码因总线错误而崩溃而内存访问的总线错误则为安全违规提供了更强的检测信号。5.3 安全启动与唯一启动入口GD32F527 的安全启动机制基于 TrustZone 构建了完整的启动保护链唯一启动入口通过 EFUSE 的 BTFOSEL 位配置可将 Flash 或 OTP1可信代码区设为唯一启动入口且配置后不可修改。若 BTFOSEL0FMC 将 SPC 保护级别设为高只能从 Flash 启动若 BTFOSEL1只能从 OTP1 启动。安全启动验证安全启动代码在用户 APP 之前执行首先检查选项字节中的安全配置SPC 保护级别、DRP 读保护、WP 写/擦保护是否正确然后使用 HASH 算法MD5、SHA-1、SHA-224 或 SHA-256验证 APP 固件的完整性。6 TrustZone 的配置方法与应用策略6.1 基础配置流程配置 Cortex-M33 的 TrustZone 通常涉及以下步骤1定义内存安全归属配置 SAU 区域将安全固件、密钥存储和敏感外设标记为 Secure将常规应用和共享资源标记为 Non-secure 或 NSC。2设置非安全域初始状态从安全状态调用tz_nonsecure_state_setup()配置非安全域的 MSP、PSP、VTOR 和 CONTROL 寄存器。3配置非安全堆栈限制通过tz_nonsecure_msplim_set()和tz_nonsecure_psplim_set()设置非安全域的堆栈边界防止堆栈溢出攻击。4异常目标状态设置通过tz_nbanked_exception_target_state_set()决定 NMI 和 BusFault 的目标安全状态。5启用 SAU调用sau_enable()激活安全归属控制。6.2 安全启动策略选择Arm 推荐的安全启动策略包括基于 ROM 的信任根将不可变的引导代码存储在 ROM 中作为系统信任根。该代码验证下一阶段固件的签名验证通过后跳转执行。基于 TrustZone 的安全启动安全启动代码运行在安全域使用 SAU 保护自身和密钥资源然后初始化非安全域并跳转至非安全应用。混合策略ROM 信任根验证安全固件安全固件再验证非安全应用形成多级信任链。6.3 安全域间通信优化TrustZone 不保证安全域与非安全域之间通信的机密性。传统的加密保护方案在低功耗 IoT 设备中开销较大。一项名为 ShieLD 的研究提出利用 MPU 构建跨域安全通道无需密码学操作即可保证机密性、完整性和认证性实测性能比传统加密方案快 5 倍。6.4 应用注意事项代码兼容性从 Cortex-M4 迁移到 Cortex-M33 时MPU 管理代码需要适配 Armv8-M 的新编程模型。C 代码在跨安全域交互时必须使用extern C链接。RTOS 部署建议Arm 建议将 RTOS 运行在非安全域以降低攻击面。RTOS 可通过安全网关调用安全域的服务。安全域最小化安全世界代码量应尽可能小。实证研究表明维持系统时间同步的安全世界增量代码可控制在118 行FreeRTOS至 280 行Zephyr。7 结论TrustZone 是 Cortex-M33 相对于 Cortex-M4 和 Cortex-M7 的架构级差异化能力其本质是将安全隔离从软件策略提升为硬件机制。通过双安全域模型、SAU/IDAU 联合归属、banked 资源隔离和总线级防火墙TrustZone 为非安全代码提供了“即使被攻陷也无法触及安全资源”的硬件保障。实测数据表明TrustZone 的性能开销可控且可预测跨域中断切换约 32 周期安全域 SysTick 处理约 120-172 周期安全世界代码增量在百行量级。对于 GD32F527 等支持 TrustZone 的 Cortex-M33 芯片合理运用这一机制可在可接受的开销下实现安全启动、密钥保护和可信执行环境等关键安全功能。在选型层面当应用需要硬件级安全隔离如安全启动、支付终端、身份认证、固件知识产权保护时Cortex-M33 的 TrustZone 具有架构性优势当应用需要最高算力或双精度浮点时Cortex-M7 仍是更合适的选择。