TF-A overview

Trusted Firmware-A

缩小到STM32MPU嵌入式软件

Trusted Firmware-A是Arm提供的安全世界软件的参考实现。^®. 它最初是为Armv8-A平台设计的，并已由意法半导体（STMicroelectronics）改编为用于Armv7-A平台。 Arm正在转让Trusted Firmware项目，该项目将由Linaro作为开源项目进行管理。

当使用STM32 MPU平台时，它用作STM32 MPU平台上的第一阶段引导加载程序（FSBL）。 trusted boot chain.

该代码在BSD-3-Clause许可下是开源的，可以在github上找到 , 包括有关Trusted Firmware-A安装的最新文档 .

Trusted Firmware-A还使用各种Arm接口标准实施安全的监视器:

• 电源状态协调接口（PSCI）
• 可信板启动要求（TBBR）
• SMC呼叫约定
• 系统控制和管理界面

Trusted Firmware-A 通常缩写为 TF-A.

Architecture

TF-A的全局体系结构在Trusted Firmware-A设计文档中进行了说明 。

TF-A分为几个二进制文件，每个都有专门的主要角色。 对于32位Arm处理器（AArch32），它分为四个步骤（按执行顺序）:

• 引导加载程序第1阶段（BL1）应用处理器受信任的ROM
• 引导加载程序第2阶段（BL2）受信任的引导固件
• 引导加载程序阶段3-2（BL32）运行时软件
• 引导加载程序阶段3-3（BL33）不可信固件

BL1，BL2和BL32是TF-A的一部分。

BL1现在是可选的，并且可以通过启用编译标志BL2_AT_EL3来删除。 然后将其删除以用于STM32MP1，因为所有BL1任务均由 ROM code或BL2完成。 BL33在TF-A之外。 这是TF-A加载的第一个非安全代码。 在引导过程中，这是二级引导加载程序（SSBL）。 对于STM32 MPU平台，默认情况下，SSBL为U-Boot。

TF-A可以使用device tree管理其配置，因为STM32MP1就是这种情况。它是Linux内核的简化版本，仅在引导过程中使用设备。可以使用STM32CubeMX进行配置。

在意法半导体（STMicroelectronics）的实现中，将2个二进制文件BL2和BL32以及设备树放到一个二进制文件中，然后通过ROM代码立即将其加载到SYSRAM中。

文件:Boot ATF legend.png

TF-A loading steps:

1. ROM code loads TF-A binary and calls BL2
2. BL2 prepares BL32
3. BL2 loads BL33
4. BL2 calls BL32
5. BL32 calls BL33

Boot loader stages

BL1

BL1 is the first stage executed, and is designed to act as ROM code; it is loaded and executed in internal RAM. It is not used for the STM32MP1. As the STM32MP1 has its own proprietary ROM code, this part can be removed and BL2 is then the first TF-A binary to be executed.

BL2

BL2 (trusted boot firmware) is in charge of loading the next-stage images (secure and non secure). To achieve this role, BL2 has to initialize all the required peripherals.

It has to initialize the security components.
For the STM32MP15, these security peripherals are:

• boot and security, and OTP control (BSEC internal peripheral)
• extended TrustZone protection controller (ETZPC internal peripheral)
• TrustZone address space controller for DDR (TZC internal peripheral)

BL2 is also in charge of initializing the DDR and clock tree.

The boot peripheral has to be initialized.
On the STM32MP15, it can be one of the following:

• SD-card via the SDMMC internal peripheral
• eMMC via the SDMMC internal peripheral
• NAND via the FMC internal peripheral
• NOR via the QUADSPI internal peripheral

USB (OTG internal peripheral) or UART(USART internal peripheral) are used when Flashing, see STM32CubeProgrammer for more details.

BL2 also integrates image verification and authentication. Authentication is achieved by calling BootROM verification services.

At the end of its execution, after having loaded BL32 and the next boot stage (BL33), BL2 jumps to BL32.

BL32

BL32 provides runtime secure services. In TF-A, the BL32 default implementation is SP_min solution. It is described in the TF-A functionality list as: "A minimal AArch32 Secure Payload (SP_MIN) to demonstrate PSCI library integration with AArch32 EL3 Runtime Software."

This minimal implementation can be replaced with a trusted OS or trusted environment execution (TEE), such as OP-TEE. Both solutions (SP_min or OP-TEE) are supported by STMicroelectronics for STM32MP1.

BL32 acts as a secure monitor and thus provides secure services to non-secure OSs. These services are called by non-secure software with secure monitor calls .

This code is in charge of standard service calls, like PSCI .

It also provides STMicroelectronics dedicated services, to access secure peripherals. On the STM32MP1, these services are used to access RCC internal peripheral, PWR internal peripheral, RTC internal peripheral or BSEC internal peripheral.

References

<securetransclude src="ProtectedTemplate:PublicationRequestId" params="9178 | 2018-10-24 | PhilipS"></securetransclude>