STM32MP157嵌入式Linux驱动开发指南》第七章 TF-A初探

正点原子运营

1）实验平台：正点原子STM32MP157开发板
2)  章节摘自【正点原子】《STM32MP157嵌入式Linux驱动开发指南》
3）购买链接:https://item.taobao.com/item.htm?&id=629270721801
4）全套实验源码+手册+视频下载地址：http://www.openedv.com/docs/boards/arm-linux/zdyzmp157.html
5）正点原子官方B站：https://space.bilibili.com/394620890
6）正点原子STM32MP157技术交流群：691905614

第七章 TF-A初探

        前面我们简单了解了一下什么是TF-A，并且也学习了如何编译TF-A。但是TF-A是如何运行的，它的一个运行流程是怎样的我们并没有讲解。TF-A的详细运行过程是很复杂的，涉及到很多ARM处理器底层知识，本章我们主要讲解一下TF-A的整个框架，了解一下TF-A运行的大致流程。



7.1 设备安全怎么保证？
        手机，已经成为人们不可缺少的一部分，相信大部分朋友出门要是忘带手机就会浑身难受，手机给我们带来的便利性自不用多说，娱乐、导航、音乐这些都是最基本的功能。移动支付这一重大创新，颠覆了我们的生活习惯，再也不需要外出的时候携带现金，只需要一部手机即可。我们在享受手机带来的便利的同时，手机安全问题就尤为重要，毕竟手机里面存放着我们的指纹、面部信息、各种银行卡和支付APP的密码。
另外，物联网行业现在也蓬勃发展，各种IOT设备层出不穷，比如各种智能插座、灯泡、摄像头等。这些IOT设备在给我们的生活带来便利性的同时，也为我们的隐私安全买下了隐患，毕竟这些设备时时刻刻监视着我们的生活环境，一旦被人突破安全防线，那么我们的生活就会暴露无遗，所以IOT设备安全也尤为重要。
设备的安全保护涉及到很多方面，本章我们讲解的TF-A主要保护的就是设备启动过程，通过各种鉴权，保证设备启动的过程中每个阶段的固件都是安全的，防止被不法分子替换某些启动固件导致安全信息泄露。
对于传统的ARM处理而言，Linux系统的启动流程就是：内部BootROMUbootkernelrootfs，整个启动过程是一个链式结构，启动过程其实是没有安全校验的(有些公司会自行定义一些校验方法)。加入TF-A固件以后，TF-A就可以对uboot、kernel进行校验，如果还要使用TEE OS(Trusted Execution Environment，TEE)，那么TF-A还要完成对TEE OS的校验。
在第五章我们已经提到了STM32MP1的安全启动(Secure Boot，有些资料也叫做安全引导)，安全启动目的是为了保证整个启动过程各个镜像的完整性，防止被不法分子破坏或替换掉。上面我们说了，Linux启动是一个链式结构，因此安全启动的鉴权(校验)过程也是链式结构的。在系统启动的过程中，会先对下一个要加载运行的镜像进行鉴权，只有鉴权成功此镜像才能运行，并进入到下一阶段，同样要先对下一阶段的镜像进行鉴权，只要其中有一环鉴权失败，那么整个系统就会启动失败。
STM32MP1使用ECDSA(Elliptic Curve Digital Signature，椭圆曲线数字签名算法)验证算法来完成鉴权，ECDSA相比RSA效果好，而且秘钥更小，STM32MP1使用256位的ECDSA秘钥。一共有两个算法用于计算ECDSA：
·P-256 NIST
·Brainpool 256
        可以在STM32MP1头部信息中定义使用哪个算法，这个在5.4小节中讲解过了，STM32MP1整个加密过程比较复杂，本教程不做讲解。STM32MP1启动的时候，内部Boot代码会对FSBL进行鉴权，然后FSBL会对后续的内容进行鉴权，这个FSBL就是TF-A。
7.2 TF-A概述
7.2.1 TF-A简介
        TF-A前面已经说了，是ARM可信任固件，是ARM官方提供的一个固件代码，它提供了统一的接口标准，方便不同的半导体厂商将自家的芯片添加到TF-A里面。ST就是在TF-A官方源码里面添加了STM32MP1系列芯片，我们在6.1.2小节对TF-A源码打过补丁，以支持STM32MP1芯片，这个补丁文件就是STM32MP1芯片对应的源码补丁文件。
        TF-A官网地址为：https://www.trustedfirmware.org/，此网站不仅仅提供了TF-A，还有针对Cortex-M单片机的TF-M，以及OP-TEE等安全相关软件库。关于TF-A官方文档我们已经放到了开发板光盘中，路径为：开发板光盘4、参考资料Trusted Firmware-A(TF-A用户手册).pdf，感兴趣的可以详细阅读此官方文档。
        TF-A一共分为5部分：bl1、bl2、bl2u、bl31、bl32和bl33，打开TF-A源码目录，可以看到这5部分，如图7.2.1所示：

图7.2.1 TF-A源码

        大家可能会有疑问，图7.2.1中并没有bl33啊，这是因为bl33是TF-A启动的其他镜像固件，比如uboot。图7.2.1中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)。
7.2.2 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处理器就有不同的运行等级，运行在低等级(非安全模式)的应用就不能访问高等级(安全模式)的资源，以此来保证敏感资源的安全性。
        1、ARMv7-A工作模式
        以前的ARMv7处理器有7中运行模型：User、FIQ、IRQ、Supervisor(SVC)、Abort、Undef和System。但新的ARMv7-A架构加入了TrustZone安全扩展，所以就新加了一种运行模式：Monitor，新的处理器架构还支持虚拟化扩展，因此又加入了另一个运行模式：Hyp，所以Cortex-A7处理器有9种处理模式，如表7.2.2.1所示：

表7.2.2.1 九种运行模式

        不同的处理器模式下，CPU对于硬件的访问权限不同，叫做Privilege Level(特权等级)，一共有两个特权级别：Privilege(特权级)和non-privilege(非特权级)。其中只有User模式处于non-privilege，也就是非特权级，剩下的8个模式都是privilege(特权级)。系统启动以后应用软件都是运行在User模式，也就是非特权级，这个时候处理器对于敏感资源的访问是受限的，如果要访问这些敏感资源就需要切换到对应的工作模式下。
        ARMv7-A对Privilege Level进行了命名：PL0和PL1，后来也出现了PL2，用于虚拟扩展。ARMv7-A新增的Monitor模式就是针对安全扩展的，为了支持TEE而引入的。
2、ARMv8工作模式
ARMv8没有Privilege level的概念，取而代之的是Exception level(异常级别)，简称为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也就是正常世界(Normal World)。我们可以在Non-secure运行通用操作系统，比如Linux，在Secure运行可信操作系统，比如OP-TEE，这两个操作系统可以同时运行，这个需要处理器支持ARM的TrustZone功能。在Normal world和Secure world下，ARMv8个EL等级对应的内容如图7.2.2.1所示：

图7.2.2.1 ARMv8在Normal和Secure下EL等级对应的不同含义

         在ARMv8的AArch32模式下，处理器模式如图7.2.2.2所示：

图7.2.2.2 AArch32下处理器模式

        从图7.2.2.2可以看出，在AArch32模式下，EL0~LE3对应ARMv7的不同工作模式：
        EL0：对应ARMv7的User工作模式。
        EL1：对应ARMv7的SVC、ABT、IRQ、IRQ、UND和SYS这6中工作模式。
        EL2：对应ARMv7的Hyp工作模式。
        EL3：对应ARMv7的Mon工作模式。
可以看出，只有EL3是用于安全监视器的，所以TF-A主要工作在EL3下，大家在看TF-A源码的时候会看到大量的“EL3”字样的文件或代码。
7.2.3 TF-A不同启动阶段
        前面说了，TF-A分为不同的启动阶段，按照链式结构依次启动，ATF代码启动流程如图7.2.3.1所示：

图7.2.3.1 TF-A启动流程

        从图7.2.3.1可以看出，当芯片复位以后首先运行bl1代码，bl1一般是芯片内部的ROM代码，bl1主要工作就是将外置Flash中的bl2固件加载到指定的RAM中，然后跳转到bl2部分。
        bl2为安全启动固件，bl 2会将剩余的三个启动阶段bl31、bl32和bl33对应的镜像文件加载到指定的内存中。比如bl32中的安全操作系统(OP-TEE)，bl31中的EL3运行时固件(Runtime Firware)，bl33中的uboot。bl2将这些固件加载完成以后就会启动相应的固件，也就是进入到第三启动阶段。
        TF-A启动流程就是：bl1 bl2( bl31/ bl32/ bl33)。注意，bl31、bl32和bl33对应的镜像不需要全部都有，但是bl33一般是必须的，因为bl33一般是uboot，这个是很重要的！
        1、bl 1
        bl 1是TF-A的第一个启动阶段，芯片复位以后就会运行bl1镜像，TF-A提供了bl1源码。但是，实际上bl1一般是半导体厂商自己编写的内部Boot ROM代码，并没有使用TF-A提供的bl1镜像，比如STM32MP1的内部ROM代码就是bl 1。因此bl1部分的实现就千差万别，不同的半导体厂商有不同的实现方法。
        一般bl1要做的就是初始化CPU，如果芯片支持不同的启动设备，那么还需要初始化不同的启动设别，比如NAND、EMMC、SD、USB或串口等。然后根据BOOT引脚的高低电平来判断当前所选择的启动设备，从对应的启动设备中加载bl2镜像，并放到对应的内存中，最后跳转到bl2镜像并运行。
        2、bl2
        bl 2会进一步的初始化芯片，比如初始化DDR、MMU、串口等。bl2会将剩下三个阶段(bl31、bl32和bl33)对应的镜像加载到指定的内存中，最后根据实际情况来启动剩下三个阶段的镜像。
        3、bl31
        在AArch64中，bl31主要是EL3的Runtime固件。
        4、bl32
        bl32一般为安全系统(TEE OS)固件，比如OP-TEE。TF-A为AArch32提供了EL3的Runtime软件，这个Runtime软件就是bl32固件，sp_min就是这个Runtime软件。大家可以打开TF-A的bl32源码文件夹，其下就有一个名为“sp_min”的子文件夹，这个就是bl32的sp_min源码，如图7.2.3.2所示：

图7.2.3.2 SP_MIN

        讲这个的主要原因是STM32MP1的bl32部分可以使用OP-TEE，也可以使用sp_min，本教程为了方便讲解，并没有使用OP-TEE，而是采用了sp_min作为bl32镜像。
        5、bl33
        bl33就是Normal World下的镜像文件，比如uboot。
        至此，我们对TF-A的基本启动流程有了一个大概的了解，我们知道了TF-A分为多个阶段，不同的阶段其工作内容不同。但是，在实际的开发中并不一定会用到TF-A中个所有启动阶段。接下来我们就会以STM32MP1为例，看一下ST是如何在自家的STM32MP1中使用TF-A的。
7.3 STM32MP1中的TF-A
7.3.1 STM32MP1 TF-A框架
        STM32MP1支持TrustZone，所以ST提供的软件包包含了安全固件。相比传统ARM处理器(如ARM9，ARM11等)最常见的uboot和linux kernel，STM32MP1的软件包还另外提供了TF-A、OP-TEE等安全相关的关键软件，因此STM32MP1的整体软件框架必然和传统的ARM芯片不同，STM32MP1软件架构如图7.3.1.1所示：

图7.3.1.1 STM32MP1软件框架

        图7.3.1.1从左到右分为三部分：Cortex-A7 Secure、Cortex-A7 Non-Secure和Cortex-M4，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：第1个阶段，一般为芯片内部ROM代码。
        bl2：第2个阶段，可信启动固件。
        bl32：EL3运行时(Runtime)软件。
        bl33：非安全固件，比如uboot。
        其中bl1、bl2和bl32都属于TF-A的一部分(如果你使用TF-A提供的bl1的话)。
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这个平台的编译选项，有如图7.3.1.2所示配置项：

图7.3.1.2 STM32MP1编译配置文件

        从图7.3.1.2可以看出，platform.mk文件定了BL2_AT_EL3为1，因此在编译STM32MP1平台对应的TF-A的时候不会编译bl1部分，STM32MP1内部ROM代码完成了TF-A中的bl1部分的工作，主要就是将外部Flash中的bl2代码加载到内部RAM中并运行。
        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接着运行。
        2、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使用哪个软件包，为了方便讲解，本教程选择sp_min。
        bl32充当安全监控(secure monitor)，因此它向非安全系统(non-secure os，比如linux)提供了一些安全服务。非安全的应用软件可以通过安全监控调用(secure monitor calls)来使用这些安全服务，这些代码支持标准的服务调用，比如PSCI。
        另外，bl32也支持ST32MP1所特有的一些安全服务，可以访问特有的安全外设，比如RCC、PWR、RTC或BSEC。
        3、STM32MP1下的bl33
        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镜像，比如我们6.2.3小节中烧写到EMMC中的tf-a-stm32mp157d-atk-trusted.stm32，其文件结构如图7.3.1.3所示：

图7.3.1.3 TF-A镜像组织结构

        STM32MP1的TF-A启动流程如图7.3.1.4所示：

图7.3.1.4 STM32MP1 TF-A启动流程

        图7.3.1.4中TF-A启动分了5步，这5步的含义如下：：
        1、复位以后内部ROM加载TF-A整个镜像，然后运行bl2镜像。
        2、bl2将bl32镜像加载到指定内存区域。
        3、bl2将bl33镜像加载到指定内存区域。
        4、bl2执行完毕以后就会跳转到bl32镜像。
        5、bl32镜像执行完以后跳转到bl33镜像，也就是uboot。
        最后，uboot引导非安全系统，也就是linux内核。
7.3.2 STM32MP1 TF-A镜像存储映射
        上一小节讲了，我们最终烧写到STM32MP1里面的TF-A镜像有4部分，除去头部信息，还有设备树、bl2和bl32。这3部分虽然在“肉体”上被打包在了一起，但是“灵魂”上是三部分，比如bl2是一个镜像，bl32是另外一个镜像，其执行顺序都是不一样的！当加载到内存上以后这3部分的存储映射如图7.3.2.1所示：

图7.3.2.1 TF-A存储分配

        图7.3.2.1中TF-A各部分存储映射不是固定的，编译TF-A的时候配置不同，其存储地址也不同。比如图7.3.2.1中BL32的起始地址为0x2FFED000，大家在看其他资料的时候可能是别的地址，这个没关系的，重点是其存储映射形式。
        关于TF-A的基础知识就讲解到这里，大家基本对TF-A有了一个初步的了解，也了解了STM32MP1中的TF-A组织形式，方便我们后续学习。