文章目录
- [1 设备安全](#1 设备安全)
- [2 TF-A简介](#2 TF-A简介)
- [3 ARMv7和ARMv8权限等级](#3 ARMv7和ARMv8权限等级)
-
- [3.1 ARMv7-A工作模式](#3.1 ARMv7-A工作模式)
- [3.2 ARMv8工作模式](#3.2 ARMv8工作模式)
- [4 TF-A不同启动阶段](#4 TF-A不同启动阶段)
-
- [4.1 bl1](#4.1 bl1)
- [4.2 bl2](#4.2 bl2)
- [4.3 bl31](#4.3 bl31)
- [4.4 bl32](#4.4 bl32)
- [4.5 bl33](#4.5 bl33)
- [5 STM32MP1中的TF-A](#5 STM32MP1中的TF-A)
-
- [5.1 STM32MP1_TF-A框架](#5.1 STM32MP1_TF-A框架)
-
- [5.1.1 STM32MP1下的bl1](#5.1.1 STM32MP1下的bl1)
- [5.1.2 STM32MP1下的bl2](#5.1.2 STM32MP1下的bl2)
- [5.1.3 STM32MP1下的bl32](#5.1.3 STM32MP1下的bl32)
- [5.1.4 STM32MP1下的bl33](#5.1.4 STM32MP1下的bl33)
- [5.2 STM32MP1_TF-A启动流程](#5.2 STM32MP1_TF-A启动流程)
- [5.3 STM32MP1_TF-A镜像存储映射](#5.3 STM32MP1_TF-A镜像存储映射)
1 设备安全
设备的安全保护涉及到很多方面，TF-A主要保护的就是设备启动过程，通过各种鉴权，保证设备启动的过程中每个阶段的固件都是安全的，防止被不法分子替换某些启动固件导致安全信息泄露。
对于传统的ARM处理而言，Linux系统的启动流程就是：内部BootROM -> Uboot -> kernel -> rootfs，整个启动过程就是一个链式结构，启动过程也没有安全校验。加入TF-A固件以后，TF-A就可以对uboot、kennel进行校验。
STM32MP1的安全启动（Secure Boot，有些资料也叫做安全引导），安全启动目的是为了保证整个启动过程各个镜像的完整性，防止被不法分子破坏或替换掉。Linux启动是一个链式结构，因此安全启动的鉴权(校验)过程也是链式结构的。在系统启动的过程中，会先对下一个要加载运行的镜像进行鉴权，只有鉴权成功此镜像才能运行，并进入到下一阶段，同样要先对下一阶段的镜像进行鉴权，只要其中有一环鉴权失败，那么整个系统就会启动失败。
2 TF-A简介
TF-A是ARM可信任固件，是ARM官方提供的一个固件代码，它提供了统一的接口标准，方便不同的半导体厂商将自家的芯片添加到TF-A里面。ST就是在TF-A官方源码里面添加了STM32MP1系列芯片，通过在源码上打补丁文件，以支持STM32MP1芯片，这个补丁文件就是STM32MP1芯片对应的源码补丁文件。
TF-A一共分为5部分：bl1、bl2、bl2u、bl31、bl32和bl33，打开TF-A源码目录，可以看到这5部分，如图所示：
图中并没有bl33，这是因为bl33是TF-A启动的其他镜像固件，比如uboot。图中bl1、bl2和bl31都属于TF-A固件，而bl32和bl33是TF-A要启动的其他第三方固件，比如TEE OS和uboot。bl1、bl2、bl31、bl32和bl33是TF-A的不同启动阶段，TF-A的启动过程是链式的，不同的阶段完整的功能不同，bl1、bl2、bl31、bl32和bl33全名如下：
- bl1 Boot loader stage 1 (BL1)；
- bl2 Boot loader stage 2 (BL2)；
- bl31 Boot loader stage 3-1 (BL31)；
- bl32 Boot loader stage 3-2 (BL32)；
- bl33 Boot loader stage 3-3 (BL33)。
3 ARMv7和ARMv8权限等级
TF-A一开始是为ARMv8准备的，ARMv8最突出的特点就是支持64位指令，但是为了兼容原来的ARMv7。ARMv8提供了两种指令集：AAarch64和AArch32，根据字面意思就是64位和32位，其中AArch32和ARMv7基本一样(会多一些其他操作指令)。STM32MP1内核为32位的Cortex-A，所以对应TF-A中的AArch32。正是因为TF-A一开始是针对ARMv8准备的，因此大家在看TF-A相关资料的时候会发现很多晦涩难懂的词汇，本来TF-A就是非常偏向底层的，需要对ARM CPU架构有一定的了解。安全不能仅仅依靠软件来实现，也是需要硬件支持的，比如ARM处理器就有不同的运行等级，运行在低等级(非安全模式)的应用就不能访问高等级(安全模式)的资源，以此来保证敏感资源的安全性。
3.1 ARMv7-A工作模式
ARMv7处理器有7种运行模型：User、FIQ、IRQ、Supervisor(SVC)、Abort、Undef和System。但新的ARMv7-A架构加入了TrustZone安全扩展，所以就新加了一种运行模式：Monitor，新的处理器架构还支持虚拟化扩展，因此又加入了另一个运行模式Hyp，所以Cortex-A7处理器有9种处理模式，如表所示：
| 模式 | 描述 |
|---|---|
| User(USR) | 用户模式，非特权模式，大部分程序运行的时候就处于此模式 |
| FIQ | 快速中断模式，进入FIQ中断异常 |
| IRQ | 一般中断模式 |
| Supervisor(SVC) | 超级管理员模式，特权模式，供操作系统使用 |
| Monitor(MON) | 监视模式，这个模式用于安全扩展模式 |
| Abort(ABT) | 数据访问终止模式，用于虚拟存储以及存储保护 |
| Hyp(HYP) | 虚拟化监控模式（仅支持虚拟化扩展的核） |
| Undef(UND) | 未定义指令终止模式 |
| System(SYS) | 系统模式，用于运行特权级的操作系统任务 |
| 不同的处理器模式下，CPU对于硬件的访问权限不同，叫做Privilege Level(特权等级)，一共有两个特权级别：Privilege(特权级)和non-privilege(非特权级)。其中只有User模式处于non-privilege，也就是非特权级，剩下的8个模式都是privilege(特权级)。系统启动以后应用软件都是运行在User模式，也就是非特权级，这个时候处理器对于敏感资源的访问是受限的，如果要访问这些敏感资源就需要切换到对应的工作模式下。ARMv7-A对Privilege Level进行了命名：PL0和PL1，后来也出现了PL2，用于虚拟扩展。ARMv7-A新增的Monitor模式就是针对安全扩展的，为了支持TEE而引入的。 |
3.2 ARMv8工作模式
ARMv8没有Privilegelevel的概念，取而代之的是Exceptionlevel(异常级别)，简称为EL用于描述特权级别，一共有4个级别：EL0、EL1、EL2和EL3，数字越大，级别越高，权限越大！这四个EL级别对应的应用场合如下：
- EL0：一般的应用程序；
- EL1：操作系统，比如Linux；
- EL2：虚拟化(Hypervisor)，虚拟机管理器；
- EL3：最底层的安全固件(安全监视器)，比如ARM Trusted Firmware(ARM安全固件，ATF，也就是TF-A)。
ARMv8提供了两种安全状态：Secure和Non-secure，也就是安全和非安全Non-secure也就是正常世界(NormalWorld)。我们可以在Non-secure运行通用操作系统，比如Linux，在Secure运行可信操作系统，比如OP-TEE，这两个操作系统可以同时运行，这个需要处理器支持ARM的TrustZone功能。在Normal world和Secure world下，ARMv8个EL等级对应的内容如图所示：
在ARMv8的AArch32模式下，处理器模式如图所示：
上图中，在AArch32模式下，EL0~LE3对应ARMv7的不同工作模式：
- EL0：对应ARMv7的User工作模式；
- EL1：对应ARMv7的SVC、ABT、FIQ、IRQ、UND和SYS这6中工作模式；
- EL2对应ARMv7的Hyp工作模式；
- EL3对应ARMv7的Mon工作模式。
只有EL3是用于安全监视器的，所以TF-A主要工作在EL3下，大家在看TF-A源码的时候会看到大量的"EL3"字样的文件或代码。
4 TF-A不同启动阶段
TF-A分为不同的启动阶段，按照链式结构依次启动，ATF代码启动流程如图所示：
上图中，当芯片复位以后首先运行bl1代码，bl1一般是芯片内部的ROM代码，bl1主要工作就是将外置Flash中的bl2固件加载到指定的RAM中，然后跳转到bl2部分。
bl2为安全启动固件，bl2会将剩余的三个启动阶段bl31、bl32和bl33对应的镜像文件加载到指定的内存中。比如bl32中的安全操作系统(OP-TEE)，bl31中的EL3运行时固件(RuntimeFirware)，bl33中的uboot。bl2将这些固件加载完成以后就会启动相应的固件，也就是进入到第三启动阶段。
TF-A启动流程就是：bl1 -> bl2 -> (bl31/bl32/bl33)。注意，bl31、bl32和bl33对应的镜像不需要全部都有，但是bl33一般是必须的，因为bl33一般是uboot，这个是很重要的！
4.1 bl1
bl1是TF-A的第一个启动阶段，芯片复位以后就会运行bl1镜像，TF-A提供了bl1源码。但是，实际上bl1一般是半导体厂商自己编写的内部BootROM代码，并没有使用TF-A提供的bl1镜像，比如STM32MP1的内部ROM代码就是bl1。因此bl1部分的实现就千差万别，不同的半导体厂商有不同的实现方法。
一般bl1要做的就是初始化CPU，如果芯片支持不同的启动设备，那么还需要初始化不同的启动设置，比如NAND、EMMC、SD、USB或串口等。然后根据BOOT引脚的高低电平来判断当前所选择的启动设备，从对应的启动设备中加载bl2镜像，并放到对应的内存中，最后跳转到bl2镜像并运行。
4.2 bl2
bl2会进一步的初始化芯片，比如初始化DDR、MMU、串口等。bl2会将剩下三个阶段(bl31、bl32和bl33)对应的镜像加载到指定的内存中，最后根据实际情况来启动剩下三个阶段的镜像。
4.3 bl31
在 AArch64中， bl31主要是 EL3的 Runtime固件。
4.4 bl32
bl32一般为安全系统(TEE OS)固件，比如OP-TEE。TF-A为AArch32提供了EL3的Runtime软件，这个Runtime软件就是bl32固件，sp_min就是这个Runtime软件。
4.5 bl33
bl33就是NormalWorld下的镜像文件，比如uboot。
5 STM32MP1中的TF-A
5.1 STM32MP1_TF-A框架
STM32MP1支持TrustZone，所以ST提供的软件包包含了安全固件。相比传统ARM处理器(如ARM9，ARM11等)最常见的uboot和linux kernel。STM32MP1的软件包还另外提供了TF-A、OP-TEE等安全相关的关键软件，因此STM32MP1的整体软件框架必然和传统的ARM芯片不同，STM32MP1软件架构如图所示：
上图从左到右分为三部分：Cortex-A7 Secure、Cortex-A7 Non-Secure和Cortex-M4。Cortex-A7 Secure、Cortex-A7 Non-Secure，也就是A7的安全和非安全两种情况。
在Cortex-A7 Secure下重点是TF-A和OP-TEE，TF-A是用于完成安全启动的，OP-TEE是TEE OS，如果使用OP-TEE的话它会和linux内核同时运行，OP-TEE负责可信应用，linux就是普通的应用程序。在Cortex-A7 Non-Secure下就是传统的ARM软件框架：uboot、linux kernel和根文件系统。
TF-A分为了不同阶段：bl1、bl2、bl31、bl32和bl33，这个主要是面向AArch64的，对于AArch32而言只有4个阶段：
- bl1：第一阶段，一般为芯片内部ROM代码；
- bl2：第二阶段，可信启动固件；
- bl32：EL3运行时(Runtime)软件；
- bl33：非安全固件，比如uboot。
其中bl1、bl2和bl32都属于TF-A的一部分(如果使用TF-A提供的bl的话)。
5.1.1 STM32MP1下的bl1
bl1部分是可选的，在编译STM32MP1的TF-A的时候可以通过添加BL2_AT_EL3编译选项来移除bl1，默认情况下ST提供的TF-A源码是有添加BL2_AT_EL3编译选项的，在TF-A源码里面找到tf-a-stm32mp-2.2.r1/plat/st/stm32mp1/platform.mk，此文件定义了STM32MP1这个平台的编译选项，有如下所示配置项：
tex
ARM_CORTEX_A7 := yes
ARM_WITH_NEON := yes
BL2_AT_EL3 := 1
USE_COHERENT_MEM := 0platform.mk文件定了BL2_AT_EL3为1，因此在编译STM32MP1平台对应的TF-A的时候不会编译bl1部分，STM32MP1内部ROM代码完成了TF-A中的bl1部分的工作，主要就是将外部Flash中的bl2代码加载到内部RAM中并运行。
5.1.2 STM32MP1下的bl2
bl2为可信启动固件，在STM32MP1中就是TF-A的bl2部分，bl2的主要功能就是加载下面几个阶段的固件到内存中，因此bl2需要初始化所要用到的外设。
首先是安全部分，STM32MP1的bl2部分会初始化的外设如下：
- BOOT、安全和OTP控制器，也就是BSEC外设；
- 扩展的TrustZone保护控制器，也就是ETZPC外设；
- TrustZone针对DDR的地址空间保护控制器，也就是TZC外设。
由于bl2需要从外部flash中加载下一阶段的镜像，因此还需要初始化一些外部flash，比如：
- SD卡；
- EMMC；
- NAND；
- NOR。
最后，STM32MP1的bl2部分还要初始化一些其他的外设，比如：
- DDR内存;
- 时钟；
- 串口，用于调试以及使用STM32CubeProgrammer的时候通过串口下载系统；
- USB，用STM32CubeProgrammer通过USB烧写系统的时候需要用到。
bl2还需要对镜像镜像进行验证和鉴权，鉴权是通过调用内部ROM代码的鉴权服务来完成。最后，bl2会加载bl32和bl33的固件到指定的内存区域，并跳转到bl32，bl32接着运行。
5.1.3 STM32MP1下的bl32
bl32提供运行时安全服务，在TF-A中默认使用sp_min，sp_min已经在前面提过了。sp_min是一个最小的AArch32安全负载(Secure Payload)，整合了PSCI库以及AArch32的EL3运行时软件。sp_min可以替代可信系统(TEE OS)或者可信执行环境(TEE)，比如OP-TEE。当然了，STM32MP1同时支持sp_min以及OP-TEE，用户可以自行选择bl32使用哪个软件包。
bl32充当安全监控(secure monitor)，因此它向非安全系统(non-secure os，比如linux)提供了一些安全服务。非安全的应用软件可以通过安全监控调用(secure monitor calls)来使用这些安全服务，这些代码支持标准的服务调用，比如PSCI。
另外，bl32也支持ST32MP1所特有的一些安全服务，可以访问特有的安全外设，比如RCC、PWR、RTC或BSEC。
5.1.4 STM32MP1下的bl33
就是传统的uboot，并不属于TF-A本身。
默认情况下TF-A有bl1、bl2、bl31、bl32和bl33这几个启动阶段。如果bl32使用sp_min的话那么bl1、bl2、bl31和bl32都属于TF-A。但是对于STM23MP1而言，因为其使用的是AArch32，因此没有bl31部分。而bl1部分ST又没有用TF-A提供的，采用的是STM32MP1内部ROM代码，因此就只剩下了bl2和bl32。所以对于STM32MP1而言，TF-A就两个固件：bl2和bl32(sp_min)，TF-A源码也采用了设备树(device tree)来设备信息，因此对于STM32MP1而言，TF-A一共有三部分：设备树、bl2和bl32，这三部分在编译的时候会被合并成一个二进制文件。还要在最前面加上重要的头部信息，最终这4部分就组成了烧写到外部flash中的TF-A镜像，其文件结构如图所示：
5.2 STM32MP1_TF-A启动流程
STM32MP1的TF-A启动流程如图所示：
上图中，TF-A启动分为了5步，这5步的含义如下：
- 复位以后内部ROM加载TF-A整个镜像，然后运行bl2镜像；
- bl2将bl32镜像加载到指定内存区域；
- bl2将bl33镜像加载到指定内存区域；
- bl2执行完毕以后就会跳转到bl32镜像；
- bl32镜像执行完以后跳转到bl33镜像，也就是uboot。
最后uboot引导非安全系统，也就是Linux内核。
5.3 STM32MP1_TF-A镜像存储映射
烧写到STM32MP1里面的TF-A镜像有4部分，除去头部信息，还有设备树、bl2和bl32。这3部分虽然在"肉体"上被打包在了一起，但是"灵魂"上是三部分，比如bl2是一个镜像，bl32是另外一个镜像，其执行顺序都是不一样的！当加载到内存上以后这3部分的存储映射如图所示：
图中TF-A各部分存储映射不是固定的，编译TF-A的时候配置不同，其存储地址也不同。比如图中BL32的起始地址为0x2FFED000，其他资料可能是别的地址，这个没关系的，重点是其存储映射形式。