TF-A（Trusted Firmware-A）及其启动流程详解：以stm32MP1平台为例

0 参考资料

stm32官网 wiki
https://www.trustedfirmware.org/
https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
Trusted Firmware-A documentation
ARM Power State Coordination Interface
SMC Calling Convention (SMCCC)
Arm System Control and Management Interface
Trusted Firmware-A Firmware Design
TF-A documentation AArch64 BL31 chapter

1 什么是TF-A？

1.1 简介

TF-A全称是Trusted Firmware-A，也就是可信固件-A，-A表示针对Cortex-A内核处理器，-M表示针对Cortex-M内核处理器。TF-A最初设计用于Armv8-A内核，ST将TF-A改造以支持其发布的基于Cortex-A7内核的stm32MP1系列处理器，在常见的基于Corte-A7的imx6ull处理器上是没有TF-A这一功能的。
以下是包含TF-A功能的stm32MP1的软件框架：
在这里插入图片描述

1.2 功能

现如今很多设备都支持联网、在线支付、语音、视频等敏感操作，为了加强设备的安全性，提出了许多保护措施。TF-A就是保护设备启动过程，通过各种鉴权，保证各个设备启动过程中的每个阶段固件都是可信赖的，避免被修改导致信息泄露等安全问题。常见的应用场景如下：
（1）智能物联网设备：保护数据安全，防止恶意攻击。
（2）移动设备：确保操作系统和关键应用的安全启动。
（3）服务器平台：保障数据中心的数据安全和可靠性。
（4）嵌入式系统：增强对敏感信息处理的安全控制。
传统的不带TF-A功能处理器的Linux系统启动流程为：内部bootloader->uboot->kernel->rootfs，整个过程没有安全校验的过程。TF-A被用于引导链上的第一阶段引导加载程序（FSBL），可以对uboot、kernel进行校验，如果还要使用 TEE OS(Trusted Execution Environment， TEE)，那么 TF-A 还要完成对TEE OS 的校验。
TF-A的代码也是开源的，遵循BSD-3-Clause许可协议。可以在https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git查看源码和实现文档。
除了对设备各阶段镜像进行安全校验，TF-A还实现了多种ARM接口标准：
（1）管理处理器和系统组件的电源和性能状态（PSCI）。
（2）定义在不同安全状态之间调用安全监控器的方法（SMC）。
（3）提供跨平台的系统控制和管理服务的通讯协议（SCMI）。

2 TF-A 启动流程

2.1 TF-A启动步骤

TF-A分为几个二进制文件，每个文件都有自己专属功能。
对于32位ARM处理器（AArch32），可信引导（启动）按顺序分为4个阶段：
（1）Boot loader stage 1 (BL1) application processor trusted ROM。引导加载阶段1（BL1）可信内部ROM程序。
（2）Boot loader stage 2 (BL2) trusted boot firmware。引导加载阶段2（BL2）受信任的引导固件。
（3）Boot loader stage 3-2 (BL32) trusted runtime firmware。引导加载阶段3-2（BL3）受信任的Runtime固件。
（4）Boot loader stage 3-3 (BL33) non-trusted firmware。引导加载阶段3-3（BL33）不受信任的固件。
对于64位ARM处理器（AArch64），可信引导（启动）按顺序分为5个阶段：
（1）Boot loader stage 1 (BL1) application processor trusted ROM。引导加载阶段1可信内部ROM程序。
（2）Boot loader stage 2 (BL2) trusted boot firmware。引导加载阶段2（BL2）受信任的引导固件。
（3）Boot loader stage 3-1 (BL31) EL3 runtime software。引导加载阶段3-1（BL31）信Runtime固件。
（4）Boot loader stage 3-2 (BL32) trusted runtime firmware。引导加载阶段3-2（BL32）受信任的Runtime固件。
（5）Boot loader stage 3-3 (BL33) non-trusted firmware。引导加载阶段3-3（BL33）不受信任的固件。
BL1、BL2、BL31（仅在AArch64平台上）是TF-A的一部分，BL32可以属于TF-A或启动第三方固件，如TEE OS和uboot。
由于stm32 MPU平台使用内部ROM代码作为BL1阶段代码，因此BL1阶段代码在TF-A中被删除。
BL33不属于TF-A。这是TF-A加载的第一个非安全镜像，也就是所谓的第二阶段引导程序(Second-Stage boot loader，SSBL)。对于STM32MP1平台而言，SSBL默认为uboot。

2.2 TF-A 启动流程图

2.2.1 32位ARM处理器

在这里插入图片描述
说明：
1.固化在ROM的加载并调用BL2
2.BL2加载BL32
3.BL2加载BL33
4.BL2调用BL32
5.BL32调用BL33

2.2.2 64位ARM处理器

在这里插入图片描述
说明：
1.固化在ROM的加载并调用BL2
2.BL2加载BL31
3.BL2加载BL32
4.BL2加载BL33
5.BL2调用BL31
6.BL31调用BL32
7.BL31调用BL33

2.3 TF-A启动阶段操作

2.3.1 BL1

BL1是启动的第一阶段，stm32MPU使用固化在内部ROM的BL1代码（不需要再自行编写），加载到RAM中运行，负责将BL2阶段镜像加载到SYSRAM。

2.3.2 BL2

BL2是启动的第二阶段，负责加载下一阶段镜像（安全或非安全）。为了实现这一目的，BL2必须初始化所有使用到的外设：
（1）系统组件：时钟、DDR、串口、MMU…
（2）安全组件：加密外设、内存防火墙…
此外，BL2使用不同的方式来加载和验证镜像是否安全。以上工作完成后，会执行BL32（32位ARM处理器）或BL31（64位ARM处理器），最终目的是执行BL33（一般是uboot）。

2.3.3 BL31

在64位ARM处理器上，BL31是EL3Runtime软件，也称为安全监视器。它处理安全监视器调优以及其他标准服务调用，例如PSCI（Power State Control Interface，电源状态控制接口）。
说明：
EL（ Exception level，异常级别），用于描述特权级别，一共有4个级别：EL0、EL1、EL2、EL3，数字越大级别越大权限越高。 4个EL 级别对应的应用场合如下：
（1）EL0：一般的应用程序。
（2）EL1：操作系统，比如 Linux。
（3）EL2：虚拟化(Hypervisor)，虚拟机管理器。
（4）EL3：最底层的安全固件(安全监视器)，比如 ARM Trusted Firmware(ARM 安全固件， ATF，也就是 TF-A)。

2.3.4 BL32

BL32提供Runtime安全服务。BL32一般为安全系统(TEE OS)固件，比如OP-TEE，TF-A 为AArch32提供了EL3的Runtime软件，这个Runtime软件就是BL32固件，sp_min就是这个Runtime软件。打开ST提供的TF-A源码可以看到该文件夹：
在这里插入图片描述

2.3.5 BL33

BL33就是正常模式(Normal World)下的镜像，比如uboot。