Armv8的安全启动

在之前汽车信息安全 -- 再谈车规MCU的安全启动文章里，我们详细描述了TC3xx 、RH850、NXPS32K3的安全启动流程，而在车控类ECU中，我们也基本按照这个流程去设计代码，同时兼顾主机厂对启动时间和安全性的要求，

但是最近在移植某国产HSM IP的固件代码时，被其安全启动流程一些概念搞得云里雾里，例如OPTEE、TF-A、RMM，SPE等等；

在Cortex-R52逐渐在区域控制器大放异彩的今天，梳理下基于Armv8的安全启动，理清这些概念，是对自己的视野拓展。

1. Trust Firmware

在Armv8架构里，ARM为安全引入了Trust Firmware作为整体解决方案，开源库地址：Trusted Firmware - Open Source Secure Software

根据官网介绍，TF为Armv8-A和Armv8-M提供了安全软件的参考实现，为SoC开发人员和oem提供了符合相关Arm规范的参考可信代码库。

其中，

• TF-A (Trusted Firmware-A，也叫ATF)是专门为Armv7\v8-A架构内核设计的参考安全固件；
• TF-M则是为Armv8-M、Armv8.1-M架构（如Cortex-M33、M55等）提供了安全处理环境（SPE，Secure Processing Environment）的参考实现。

那么今天就从TF-A开始，先把最抽象的啃点，再看TF-M就容易理解很多。

2. TF-A启动流程

TF-A（AArch64）的启动引导过程一共分为5个单独启动阶段，每个阶段运行在不同的内核异常等级，流程如下：

每个阶段功能定义如下：

• BL1(Boot Loader stage 1)：BL1一般指运行存放在芯片内部BootROM的代码，这部分代码由SoC厂商在芯片流程时固化进去，不能再做修改；该阶段运行在Armv8的EL3等级，如果支持安全启动，BootROM在构建信任链的时候就显得尤为关键，主要用于校验BL2 Boot Firmware并完成加载和跳转，这也是和目前接触过的车规MCU安全启动流程最明显的区别；
• BL2(Boot Loader stage 2:)：Boot Firmware由BL1从引导介质中（例如NOR Flash、SD/eMMC）加载运行（例如DDR），它的主要作用是初始化平台所需要存储介质、配置MMU、校验BL31\32\33并完成加载等，值得注意，BL2依旧运行在EL3等级。
• BL31(Boot Loader Stage 3-1)：BL2加载BL31后，并把控制权交由BL31（此时仍旧运行在EL3等级），从上图可以看到BL31仍旧需要运行在可信RAM中，它主要为引导加载程序和操作系统提供初始化服务，例如GIC初始化、电源控制设备初始化、MMU使能和重定向等等；完成上述初始化后，如有BL32 trusted OS镜像，BL31加载BL32并跳转运行；
• BL32：可信的操作系统，例如OP-TEE(Open source Project Trusted Execution Environment )、安卓Trusty TEE
• BL33：常见的Bootloader（U-Boot/UEFI），运行在Armv8 EL2等级，完成启动后运行Kernel

在开源库中每个阶段都可以单独进行编译，因此很明显启动流程可以根据需求进行裁剪，

但值得一提的是，上述启动流程有个前提假设：那就是这些镜像文件存储的物理介质一般都不支持xip，所以需要在启动时将上述镜像加载到SRAM或者DDR上运行；这是与带有eFlash的MCU的安全启动流程的另一个明显区别。

既如此，我们就来看看TF-M的流程。

3. TF-M启动流程

TF-M(Trusted Firmware-M)主要是为Armv8-M架构的内核提供了一个安全运行处理环境（SPE），如下图所示：

如上图所示，TF-M包含了上图深蓝色框的所有功能，其中蓝底背景的叫做PSA-RoT（Platform Security Architecture Root of Trust），主要功能模块包括：

• Secure Boot：用于验证SPE和NSPE的镜像是否可信；
• TF-M Core：用于SPE和NSPE的安全通信（IPC）、中断处理、隔离等等；
• 加解密服务、安全存储、受保护存储、安全升级等等

今天主要看看Secure Boot。

与TF-A，TF-M的安全启动只分为了BL1和BL2。

3.1 BL1

BL1 Immutable bootloader：翻译过来就是不可变的引导程序，它在安全启动时和公钥(ROTPK)共同构成信任根，因此这段bootloader代码必须存储在ROM或者支持写保护的Flash，ROTPK可以存放在OTP。

如果一些芯片本身ROM就有启动代码且没有安全Flash存储TF-M，那么TF-M的BL1就必须进行验证，以保证信任链的构建。

从这里突然就反应过来，之前英飞凌TC3xx提出的安全启动方案要求HSM BL存放在OTP中，很大部分原因就是HSM的BootROM并没有提供任何验证HSM BL的机制。

3.2 BL2

在TF-M中，BL2默认使用MCUboot开源代码，链接https://github.com/mcu-tools/mcuboot。它是整个安全启动的核心所在，主要用于验证其他固件的身份和完整性，但由于这部分又是开源的，因此每家芯片厂在实现时又会有所差别。

以STM32U5为例，基于MCUboot框架设计了SBSFU（Secure Boot and Secure Firmware Update），主要用于安全启动和安全升级。它将这部分代码固定在Flash存储器某个位置，这时候从PSA架构和TFM secure boot程序映射可以满足要求，如下：

一旦从TFM_SBSFU_Boot (Secure Boot and Secure Firmware Update software)应用程序跳转到安全应用程序时，所有专用于执行TFM_SBSFU_Boot 的 Flash 存储器区域均被隐藏，安全和非安全主插槽区域允许执行。

PS:HDP(secure hide-protection area)

SBSFU提供了多种验签和加密机制，如下：

同时也给出了安全启动的时间评估参数：

4.小结

随着ARM内核的MCU逐渐进入到汽车市场，必须要掌握TF-A\M的一些概念；同时我也很好奇，像Steller这种R52内核的芯片是如何设计其安全启动流程。毕竟在HSM普及的今天，信任根的变化会影响一个系统的架构设计，