TF-A overview

1. Trusted Firmware-A

Zoom out to STM32MPU Embedded Software

Trusted Firmware-A is a reference implementation of secure-world software provided by Arm^®. It was first designed for Armv8-A platforms, and has been adapted to be used on Armv7-A platforms by STMicroelectronics. Trusted Firmware-A is part of the Trusted Firmware project that is an open governance community project hosted by Linaro.

It is used as the first-stage boot loader (FSBL) on STM32 MPU platforms when using the trusted boot chain.

The code is open source, under a BSD-3-Clause license, and can be found on linaro project page , including an up-to-date documentation about Trusted Firmware-A implementation .

Trusted Firmware-A also implements a set of features with various Arm interface standards:

• The power state coordination interface (PSCI)
• SMC calling convention
• System control and management interface

The Trusted Firmware-A implement a minimal AArch32 Secure Payload (SP_MIN) to demonstrate PSCI library integration with AArch32 EL3 Runtime Software.

Trusted Firmware-A is usually shortened to TF-A.

2. Architecture

The global architecture of TF-A is explained in the Trusted Firmware-A design document.

TF-A is divided into several binaries, each with a dedicated main role.
For 32-bit Arm processors (AArch32), trusted boot is divided into four stages (in order of execution):

• Boot loader stage 1 (BL1) application processor trusted ROM
• Boot loader stage 2 (BL2) trusted boot firmware
• Boot loader stage 3-2 (BL32) runtime software
• Boot loader stage 3-3 (BL33) non-trusted firmware

BL1, BL2 and BL32 are parts of TF-A.

Because STM32MP platforms use a dedicated ROM code, BL1 boot stage is then removed. ROM code expect the BL2 to run at EL3 execution level. This mode is selected when BL2_AT_EL3 build flag is enabled.

BL33 is outside of TF-A. This is the first non-secure code loaded by TF-A. During the boot sequence, this is the secondary stage boot loader (SSBL). For STM32 MPU platforms, the SSBL is U-Boot by default.

TF-A can manage its configuration with a device tree, as this is the case on STM32MP1. In the BL2 stage, it is a reduced version of the Linux kernel one, with only the devices used during boot. It can be configured with STM32CubeMX.

TF-A loading steps:

1. ROM code loads and calls BL2
2. BL2 loads BL32
3. BL2 loads BL33
4. BL2 calls BL32
5. BL32 calls BL33

3. Boot loader stages

3.1. 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 STM32 MPU. STM32 MPU have its own proprietary ROM code, this part can be removed and BL2 is then the first TF-A binary to be executed.

3.2. BL2

BL2 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.

• System components : clocks, ddr, ...
• Security components : Firewall
• Storage

BL2 offers different features to load and authenticate images.

3.2.1. FIP

The Firmware Image Package (FIP) is a TF-A archive binary that encapsulate bootloader images into a single archive. It can also contain other data such as certificates that are required to complete boot process. A dedicated driver drivers/io/io_fip.c able to read datas from this package is part of the TF-A BL2.
FIP uses a specific layout base on a table of contents followed by payload data. It is synchronize between the driver and the host creation tool: fiptool tools/fiptool/fiptool.c . This host tool is able to create a package, get info from the package, update, unpack or remove data in this package.

3.2.2. FCONF

The Firmware Configuration Framework (FCONF) is a way for more flexibility in to the firmware. It is used to provide the most of the platform-specific data that were hard coded inside the firmware. This framework uses device tree (one or multiple) than are passed to the firmware during load. BL2 will use it for the chain of trust description, list of images to be loaded.
Thanks to device tree usage, the configuration becomes dynamic at boot time. Current implementation use the following device tree as framework entry:

• FW_CONFIG - The firmware configuration file. Holds properties shared across all BLx images. An example is the ?dtb-registry? node, which contains the information about other binaries configuration (load-address, size, image_id).
• HW_CONFIG - The hardware configuration file. Can be shared by all Boot Loader stages and also by the Normal World Rich OS.
• TB_FW_CONFIG - Trusted Boot Firmware configuration file. Shared between BL1 and BL2.
• SOC_FW_CONFIG - SoC Firmware configuration file. Used by BL31.
• TOS_FW_CONFIG - Trusted OS Firmware configuration file. Used by Trusted OS (BL32).
• NT_FW_CONFIG - Non Trusted Firmware configuration file. Used by Non-trusted firmware (BL33).

3.2.3. Authentication

TF-A BL2 implements an authentication framework that use a Chain of Trust (CoT) to achieve a secure boot. The CoT used is the TBBR CoT based on Arm TBBR requirement. TF-A BL2 implements this CoT based on a Root of Trust Public Key (ROTPK). The CoT relies on a public key infrastructure generating self-signed certificate (followed X509v3 ). There is no Certificate Authority (CA) because the CoT is not established by verifying the validity of a certificate's issuer.

Different keys are used for this CoT:

• Root of trust key - The private part of this key is used to sign the BL2 content certificate and the trusted key certificate. The public part is the ROTPK.
• Trusted world key - The private part is used to sign the key certificates corresponding to the secure world images (SCP_BL2, BL31 and BL32). The public part is stored in one of the extension fields in the trusted world certificate.
• Non-trusted world key - The private part is used to sign the key certificate corresponding to the non secure world image (BL33). The public part is stored in one of the extension fields in the trusted world certificate.
• BL3X keys - For each of SCP_BL2, BL31, BL32 and BL33, the private part is used to sign the content certificate for the BL3X image. The public part is stored in one of the extension fields in the corresponding key certificate.

The certificates used in this CoT could be Key certificate or Content certificate.

• BL2 content certificate - It is self-signed with the private part of the ROT key. It contains a hash of the BL2 image.
• Trusted key certificate - It is self-signed with the private part of the ROT key. It contains the public part of the trusted world key and the public part of the non-trusted world key.
• SCP_BL2 key certificate - It is self-signed with the trusted world key. It contains the public part of the SCP_BL2 key.
• SCP_BL2 content certificate - It is self-signed with the SCP_BL2 key. It contains a hash of the SCP_BL2 image.
• BL31 key certificate - It is self-signed with the trusted world key. It contains the public part of the BL31 key.
• BL31 content certificate - It is self-signed with the BL31 key. It contains a hash of the BL31 image.
• BL32 key certificate - It is self-signed with the trusted world key. It contains the public part of the BL32 key.
• BL32 content certificate - It is self-signed with the BL32 key. It contains a hash of the BL32 image.
• BL33 key certificate - It is self-signed with the non-trusted world key. It contains the public part of the BL33 key.
• BL33 content certificate - It is self-signed with the BL33 key. It contains a hash of the BL33 image.

File:Tfa cot tbbr.png

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

3.3. BL32

BL32 provides runtime secure services. On ARMv7 architecture, the BL32 must embed a Secure Monitor as it will be executed in the same privilege level (PL1-SVC Secure). TF-A provides a minimal monitor implementation: SP-MIN. 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 that also embeds a secure monitor on Armv7. Both solutions (SP-MIN or OP-TEE) are supported by STMicroelectronics for STM32MP15.

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 or SCMI (ref name=scmi/>.

It also provides STMicroelectronics proprietary services to access secure peripherals (with secure access control).

Arm^® is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere.

First Stage Boot Loader

Microprocessor Unit

Power State Coordination Interface

Secure Monitor Call

Trusted Firmware for Arm^® Cortex^®-A

Boot Loader stage 1

Read Only Memory

Boot Loader stage 2

Boot Loader stage 3-2

Boot Loader stage 3-3

Second Stage Boot Loader

Linux^® is a registered trademark of Linus Torvalds.

Random Access Memory (Early computer memories generally hadserial access. Memories where any given address can be accessed when desired were then called "random access" to distinguish them from the memories where contents can only be accessed in a fixed order. The term is used today for volatile random-acces ssemiconductor memories.)

Firmware Image Package is a packaging format used by TF-A

Firmware Configuration Framework used by TF-A - NEW

Operating System

Chain of Trust

Secure coprocessor

Secure Payload minimal

Trusted Execution Environment

Open Portable Trusted Execution Environment

System control and management interface