SOC- armv8 启动流程和安全启动

一、启动的软件架构，即bootloader 有哪几部分

（1）芯片的bootrom 固件，每个芯片厂家不一样；

（2）ATF 固件，即 arm-trusted-firmware; 有一个开源的ATF：TF-A/trusted-firmware-a.git - TrustedFirmware Git 浏览器

（3）uboot;

(4) kernel;（不算bootloader 的范畴）

二、启动流程

Armv8的启动流程包含多个阶段，典型地有BL1、BL2、BL31、BL32、BL33，根据需求的不同，这些阶段可以适当地裁剪或添加。为了方便描述，后面我们的讨论将基于以上这些官方定义的标准阶段，它们的源码会被编译成独立的启动镜像，并被保存到特定的存储介质中。由于一般的存储介质（如spi flash、nand flash、emmc、ssd等）都不支持代码的直接执行，因此需要在启动时先将镜像加载到可直接执行代码的存储介质，如SRAM或DDR中，然后运行相关代码。其典型的加载流程如下：

1. BL1是启动的第一阶段，该镜像必须要存储在可直接执行的介质中。若芯片支持XIP启动方式，其可被存储在片外可直接执行的介质中（如norflash）。若不支持XIP，则需要存储在芯片的片内ROM中，此时在芯片出厂后该部分代码就将被固化，后续再也不能被修改和升级。若芯片要支持安全启动，则需要将bootrom作为启动时的信任根，此时除调试阶段外，SOC必须禁用XIP。关于安全启动我们在第三部分介绍；
2. BL2镜像由BL1加载，此时DDR还没有被初始化，因此它需要被加载到片内的SRAM中执行，一般在这个阶段会完成DDR的初始化，因此后面的镜像都可以被加载到DDR中。从上图可知，BL31、BL32和BL33都是由BL2加载的，其中BL31和BL32是可选的，若系统不支持TRUST OS，则可去掉BL32，若不支持EL3异常等级及secure monitor，则可去掉BL31
3. BL33一般指uboot，一般通过它最终启动操作系统内核

Armv8架构典型的启动流程如下：

以上流程中我们假定系统支持的最高异常等级为EL3，且支持secure monitor和TRUST OS，同时BL2运行在secure EL1，BL33运行在non secure EL1或non secure EL2状态

（1）由于armv8架构规定，arm核复位后默认会进入当前系统支持的最高异常等级，因此BL1运行在EL3，它执行完成后会通过异常返回ERET的方式跳转到BL2

（2 - 3）BL2执行完成后需要跳转到BL31，由于BL31运行在EL3异常等级，而BL2根据需求不同可能运行于secure EL1或EL3。当BL2运行于EL3时可直接通过ERET方式跳转到BL31中，但若其运行在secure EL1时，则只能通过smc异常触发进入EL3异常等级。

显然，此时BL31由于尚未设置其自身的smc异常处理程序而无法直接处理该异常，因此，为了完成跳转流程，BL1需要先代理该异常的处理。因此BL1在退出之前先设置smc异常处理函数，BL2触发smc启动BL31时，BL1捕获该异常并根据BL2传入的参数设置BL31的入口地址和系统初始状态，并通过ERET跳转到BL31的入口地址处执行

（4）BL32阶段会运行TRUST OS，它运行于secure EL1异常等级，BL31可根据其镜像加载信息设置入口地址以及其它状态，并完成跳转

（5 - 6）BL32加载完成后将通过SMC返回到BL31，然后由BL31跳转到non secure EL1或non secure EL2以执行BL33

上面这部分总结就是：如何通过异常处理，来启动整个 bl1，bl2, bl31,bl32,bl33;

三、TF-A 安全启动

在Armv8架构里，ARM为安全引入了Trust Firmware作为整体解决方案，开源库地址：TF-A/trusted-firmware-a.git - TrustedFirmware Git 浏览器

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

其中，

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（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的安全启动流程的另一个明显区别。

其实比较复杂一点的地方就是 BL31 的 secure monitor 和 BL32 的OP-TEE 可信操作系统；这是因为这个两个系统，不会把占用的内存进行回收，是一直占用内存，也是专业一点的名字就是runtime service ,提供运行时的服务。当有异常产生时，会调用里面的函数进行执行。这里不展开具体的代码展示。

提供OP-TEE的搭建说明：

里面有ARM V7和ARM V8两个架构的搭建说明，官方部分ARM V8的相关指令如下：

$ mkdir optee
$ cd optee
$ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml
$ repo sync
$ cd build
$ make toolchains
$ make run

由于国内访问有限制，需要在上面的基础上做一些简单的改动，修改repo默认的镜像源地址，如下即可：

Ubuntu 22.04/20.04


$ mkdir optee

$ cd optee
$ curl https://mirrors.tuna.tsinghua.edu.cn/git/git-repo -o ~/bin/repo
$ chmod a+x ~/bin/repo

$ export PATH=~/bin:$PATH
$ vim ~/.bashrc

//将以下内容添加到.bashrc的末尾
export REPO_URL='https://mirrors.tuna.tsinghua.edu.cn/git/git-repo'

//重新启动终端,继续以下命令
$ repo init -u https://github.com/OP-TEE/manifest.git -m qemu_v8.xml

$ repo sync

$ cd build

$ make toolchains

$ sudo make plat=qemu -j3 run

编译时间会比较长，另外如果是虚拟机的话，建议一开始存储内存就给的稍微多一些

执行完最后的命令后会出现三个终端（Normal World、Secure World、命令行shell终端）

在qemu后面输入c，启动两个系统的运行

其中Normal终端中的打印的为BL1 - BL3启动阶段，非安全部分的LOG，以及从BL3跳转到UBOOT并从UBOOT引导Linux的所有输出

Secure World为OP-TEE OS的输出LOG。

四、镜像跳转方式

前面我们聊到镜像跳转时可能需要使用到ERET或SMC指令，下面我们再看下跳转时的细节

4.1 Smc异常处理流程

smc是armv8支持的异常跳转指令，它用于程序从EL1或EL2跳转到EL3异常等级。其跳转流程如下：

以atf的BL1 smc处理流程为例，EL1调用者通过smc指令陷入到EL3异常，此后CPU将跳转到EL3异常向量表的vector_entry SynchronousExceptionA64入口处，该函数解析esr_el3寄存器的异常原因，若其为smc异常，就跳转到smc处理函数smc_handler64中。smc_handler64解析通过x0 -- x7寄存器传入的参数获取smc命令类型，执行特定的命令处理函数，并通过寄存器x0 -- x4返回处理结果。对于异常向量表跳转入口选择原则可参考以下博文：
lgjjeff：armv8中断路由机制

4.2 ERET跳转流程

ERET指令用于从异常处理流程中返回，在介绍异常返回流程之前，我们先看一下armv8异常跳转的流程。Armv8触发异常或中断后硬件将会执行以下操作：

（1）将PSTATE寄存器的内容保存到SPSR_ELx中，其中x表示异常进入的异常等级，如smc异常将会陷入EL3，因此相应的寄存器就为SPSR_EL3

（2）将异常处理完成后需要返回的地址保存在ELR_ELx中

（3）设置中断和异常掩码DAIF，以关闭所有中断和异常

（4）若异常是同步异常或SError中断，异常状态信息将被保存在ESR_ELx中，该信息可用于分析异常发生的原因

（5）若异常为指令异常、数据异常或对齐错误等，则触发异常对应的内存地址将被保存到FAR_ELx寄存器中

（6）栈指针切换为目标异常等级的栈指针寄存器SP_ELx

（7）程序跳转到对应的异常处理入口，执行异常处理程序

在异常执行完成后，可通过ERET指令返回被异常中断程序的断点处继续执行，该指令将使硬件执行以下操作：

（1）用SPSR_ELx寄存器的内容恢复PSTATE寄存器

（2）用ELR_ELx寄存器的内容恢复PC值

从以上流程可以看到，执行ERET指令后程序的执行流将由SPSR_ELx和ELR_ELx决定。因此，我们在执行镜像之间的跳转，只要在ERET之前将ELR_ELx设置为待跳转镜像的入口地址，并设置正确的SPSR_ELx即可完成

五、内存规划

5.1 内存规划原则

嵌入式系统的内存一般包含ROM、SRAM和DDR，其中ROM和SRAM位于SOC片内，DDR位于芯片外部。它们的特点如下：

（1）ROM中的内容断电后不会消失，不仅可用于代码执行，还可以用于镜像存储，但其只有只读权限

（2）SRAM和DDR中的内容在断电后都会消失，因此只能被用于代码的动态执行，而不能用于镜像存储

（3）ROM和SRAM都是直接连接总线上，系统上电后即可直接执行。而DDR需要通过DDR phy和DDR controller连接到总线上，因此使用之前必须要先对其执行初始化操作

根据上述各种内存的特点和前面镜像加载启动流程的需求，在内存规划中我们需要考虑以下几个问题：

（1）由于BL1需要固化到ROM中，且是系统最先执行的，因此ROM地址需要被映射到cpu的重启地址处

（2）由于ROM是只读的，BL1镜像除了代码段和只读数据段之外还包含可读写数据段，这部分数据在BL1启动时需要从ROM重定位到SRAM中

（3）由于BL1被固化在ROM中，芯片出产后就不能更改，因此DDR初始化代码不能集成到BL1中。故BL2需要被加载到SRAM中执行，且在BL2中执行DDR初始化流程

（4）BL2之后的其它镜像既可以运行于SRAM中，也可以运行于DDR中

（5）从前面的镜像启动流程可知，若BL2运行于secure EL1下，当其执行完成后，需要通过smc再次陷入BL1去执行BL31流程，因此BL2和BL1的地址不能有重叠

（6）BL31除了执行启动流程外，在系统运行过程中还会以secure monitor的方式驻留，为normal空间的smc异常提供服务历程，以及为normal os和trust os之间提供消息转发、中断路由转发等功能。因此，BL31镜像需要永久驻留内存，在系统启动完成后不能被回收

（7）与BL31类似，BL32在启动后需要驻留内存为系统提供安全相关服务，因此为其所分配的内存也不能被回收（8）除此之外，BL1、BL2和BL33（一般为uboot）的内存在系统启动完成后都可以被释放给操作系统使用。

5.2 qemu virt平台内存规划示例

根据以上内存规划原则，qemu virt machine各启动阶段的内存规划如下：

|------|------------|-------------|------|------------|--------------|
| 类型 | 起始地址 | 结束地址 | 长度 | 是否secure内存 | 作用 |
| ROM | 0x00000000 | 0x00020000 | 128k | Yes | BL1（bootrom） |
| SRAM | 0x0e04e000 | 0x0e060000 | 72k | Yes | Bl1（rw data） |
| SRAM | 0x0e000000 | 0x0e001000 | 4k | Yes | Shared ram |
| SRAM | 0x0e01b000 | 0x0e040000 | 148k | Yes | BL2 |
| SRAM | 0x0e040000 | 0x0e060000 | 128k | Yes | BL31 |
| SRAM | 0x0e001000 | 0x0e040000 | 252k | YES | BL32 |
| DDR | 0x60000000 | 0x100000000 | 2.5G | NO | BL33 |

从上面的BL31和BL32的内存规划，是占用的SRAM空间，不是占用DDR空间，也就是OP-TEE系统（BL32）和sercure monitor (BL31)是占用SRAM内存，不是DDR内存 。