Registered User mNo edit summary |
Registered User No edit summary |
||
(11 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
{{ApplicableFor | |||
|MPUs list=STM32MP13x, STM32MP15x | |MPUs list=STM32MP13x, STM32MP15x, STM32MP21x, STM32MP23x, STM32MP25x | ||
|MPUs checklist=STM32MP13x,STM32MP15x | |MPUs checklist=STM32MP13x, STM32MP15x, STM32MP21x, STM32MP23x, STM32MP25x | ||
}}</noinclude> | }} | ||
<noinclude></noinclude> | |||
== Trusted Firmware-A == | == Trusted Firmware-A == | ||
[[File: STM32MPU Embedded Software architecture overview.png|link=STM32MPU Embedded Software architecture overview|thumb|Zoom out to STM32MPU Embedded Software]] | [[File: STM32MPU Embedded Software architecture overview.png|link=STM32MPU Embedded Software architecture overview|thumb|Zoom out to STM32MPU Embedded Software]] | ||
Trusted Firmware-A is a reference implementation of secure-world software provided by Arm<sup>®</sup>. 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 | Trusted Firmware-A is a reference implementation of secure-world software provided by Arm<sup>®</sup>. 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 Trusted Firmware Group.<ref>https://www.trustedfirmware.org/</ref> | ||
It is used as the first-stage boot loader (FSBL) on STM32 MPU platforms | It is used as the first-stage boot loader (FSBL) on STM32 MPU platforms [[Boot_chain_overview|boot chain]]. | ||
The code is open source, under a BSD-3-Clause license, and can be found on | The code is open source, under a BSD-3-Clause license, and can be found on Trusted Firmware project page | ||
<ref>https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git</ref>, including an up-to-date documentation about Trusted Firmware-A implementation <ref name=TrustedFirmware> {{DocSource | domain=TF-A | path=index.html | text=Trusted Firmware-A documentation}}</ref>. | <ref>https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git</ref>, including an up-to-date documentation about Trusted Firmware-A implementation <ref name=TrustedFirmware> {{DocSource | domain=TF-A | path=index.html | text=Trusted Firmware-A documentation}}</ref>. | ||
Trusted Firmware-A also implements a set of features with various Arm interface standards: | Trusted Firmware-A also implements a set of features with various Arm interface standards: | ||
* | * Power state coordination interface (PSCI) <ref name=psci>[https://developer.arm.com/documentation/den0022/ ARM Power State Coordination Interface]</ref> | ||
* SMC calling convention <ref name=smc>[https://developer.arm.com/documentation/den0028/ SMC Calling Convention (SMCCC)]</ref> | * SMC calling convention <ref name=smc>[https://developer.arm.com/documentation/den0028/ SMC Calling Convention (SMCCC)]</ref> | ||
* System control and management interface <ref name=scmi>[https://developer.arm.com/documentation/den0056/ Arm System Control and Management Interface]</ref> | * System control and management interface (SCMI)<ref name=scmi>[https://developer.arm.com/documentation/den0056/ Arm System Control and Management Interface]</ref> | ||
Trusted Firmware-A is usually shortened to TF-A. | Trusted Firmware-A is usually shortened to TF-A. | ||
Line 31: | Line 32: | ||
* Boot loader stage 3-3 (BL33) non-trusted firmware | * Boot loader stage 3-3 (BL33) non-trusted firmware | ||
BL1 and | For 64-bit Arm processors (AArch64), the trusted boot is divided into five 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-1 (BL31) EL3 runtime software | |||
* Boot loader stage 3-2 (BL32) trusted runtime firmware | |||
* Boot loader stage 3-3 (BL33) non-trusted firmware | |||
BL1, BL2 and BL31 (only on AArch64 platforms) are parts of TF-A, BL32 can be either in TF-A or outside (for example OP-TEE). | |||
Because STM32 MPU platforms uses a dedicated [[:Category:ROM code|ROM code]], the BL1 boot stage is then removed. [[:Category:ROM code|ROM code]] expects the BL2 to run at EL3 execution level. This mode is selected when the BL2_AT_EL3 build flag is enabled. | Because STM32 MPU platforms uses a dedicated [[:Category:ROM code|ROM code]], the BL1 boot stage is then removed. [[:Category:ROM code|ROM code]] expects the BL2 to run at EL3 execution level. This mode is selected when the BL2_AT_EL3 build flag is enabled. | ||
Line 37: | Line 45: | ||
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 overview|U-Boot]] by default. | 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 overview|U-Boot]] by default. | ||
TF-A can manage its configuration with a [[STM32_MPU_device_tree#Device tree structure|device tree]]. In the BL2 stage, it is a reduced version of the Linux kernel one, with only the required devices used during boot. | TF-A can manage its configuration with a [[STM32_MPU_device_tree#Device tree structure|device tree]]. In the BL2 stage, it is a reduced version of the Linux kernel one, with only the required devices used during boot. On AArch64 platforms, BL31 also has a dedicated device tree. They can be configured with [[STM32CubeMX]]. | ||
=== Boot on AArch32 platform === | |||
[[File:Boot_ATF.png|center|upright=2]] | [[File:Boot_ATF.png|center|upright=2]] | ||
Line 47: | Line 56: | ||
# BL2 calls BL32 | # BL2 calls BL32 | ||
# BL32 calls BL33 | # BL32 calls BL33 | ||
=== Boot on AArch64 platform === | |||
[[File:TF-A_boot_aarch64.png|center|upright=2]] | |||
TF-A loading steps: | |||
# ROM code loads and calls BL2 | |||
# BL2 loads BL31 | |||
# BL2 loads BL32 | |||
# BL2 loads BL33 | |||
# BL2 calls BL31 | |||
# BL31 calls BL32 | |||
# BL31 calls BL33 | |||
== Boot loader stages == | == Boot loader stages == | ||
Line 63: | Line 84: | ||
[[TF-A_BL2_overview|BL2 offers different features]] to load and authenticate images. | [[TF-A_BL2_overview|BL2 offers different features]] to load and authenticate images. | ||
At the end of its execution, after having loaded BL32 and the next boot stage (BL33), BL2 jumps to BL32. | At the end of its execution, after having loaded BL32 and the next boot stage (BL33), BL2 jumps to BL31 (AArch64) or BL32 (AArch32). | ||
=== BL31 === | |||
On 64-bit Arm processors (AArch64), BL31 is the EL3 Runtime Software, also called Secure Monitor. More information can be found in TF-A documentation AArch64 BL31 chapter<ref> {{DocSource | domain=TF-A | path=design/firmware-design.html#aarch64-bl31 | text=TF-A documentation AArch64 BL31 chapter}}</ref>. It handles secure monitor calls <ref name=smc/>, and other standard service calls, like PSCI <ref name=psci/>. | |||
=== BL32 === | === BL32 === | ||
BL32 provides runtime secure services. | BL32 provides runtime secure services. | ||
==== AArch32 platforms ==== | |||
On Armv7 architecture, the BL32 must embed a Secure Monitor as it will be executed in the same privilege level (PL1-SVC Secure). | On Armv7 architecture, the BL32 must embed a Secure Monitor as it will be executed in the same privilege level (PL1-SVC Secure). | ||
Before {{EcosystemRelease | revision=5.0.0}}, the minimal TF-A BL32 monitor support was provided. This is no more the case. | Before {{EcosystemRelease | revision=5.0.0}}, the minimal TF-A BL32 monitor support was provided. This is no more the case. | ||
{{Info|SP_MIN is no more supported. [[OP-TEE overview|OP-TEE]] is the BL32 official solution.}} | {{Info|SP_MIN is no more supported. [[STM32 MPU OP-TEE overview|OP-TEE]] is the BL32 official solution.}} | ||
STMicroelectronics provides [[OP-TEE overview|OP-TEE]] support that also embeds a secure monitor on Armv7. | STMicroelectronics provides [[STM32 MPU OP-TEE overview|OP-TEE]] support that also embeds a secure monitor on Armv7. | ||
It can be replaced with a trusted OS or another trusted environment execution (TEE). | It can be replaced with a trusted OS or another trusted environment execution (TEE). | ||
Line 81: | Line 106: | ||
It also provides STMicroelectronics proprietary services to access some specific and limited secure peripherals (with secure access control). | It also provides STMicroelectronics proprietary services to access some specific and limited secure peripherals (with secure access control). | ||
==== AArch64 platforms ==== | |||
On AArch64 platforms, BL32 (OP-TEE) is in charge of runtime secure services, like SCMI <ref name=scmi/>. | |||
==References== | ==References== | ||
Line 86: | Line 115: | ||
<noinclude> | <noinclude> | ||
[[Category:Trusted Firmware-A | [[Category:Trusted Firmware-A| 01]] | ||
{{PublicationRequestId | 19292 (Previous 9178) | 2120-03-10 | PhilipS}} | {{PublicationRequestId | 19292 (Previous 9178) | 2120-03-10 | PhilipS}} | ||
</noinclude> | </noinclude> |
Latest revision as of 11:54, 29 October 2024
1. Trusted Firmware-A[edit | edit source]
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 Trusted Firmware Group.[1]
It is used as the first-stage boot loader (FSBL) on STM32 MPU platforms boot chain.
The code is open source, under a BSD-3-Clause license, and can be found on Trusted Firmware project page [2], including an up-to-date documentation about Trusted Firmware-A implementation [3].
Trusted Firmware-A also implements a set of features with various Arm interface standards:
- Power state coordination interface (PSCI) [4]
- SMC calling convention [5]
- System control and management interface (SCMI)[6]
Trusted Firmware-A is usually shortened to TF-A.
2. Architecture[edit | edit source]
The global architecture of TF-A is explained in the Trusted Firmware-A design [7] document.
TF-A is divided into several binaries, each with a dedicated main role.
For 32-bit Arm processors (AArch32), the 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) trusted runtime firmware
- Boot loader stage 3-3 (BL33) non-trusted firmware
For 64-bit Arm processors (AArch64), the trusted boot is divided into five 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-1 (BL31) EL3 runtime software
- Boot loader stage 3-2 (BL32) trusted runtime firmware
- Boot loader stage 3-3 (BL33) non-trusted firmware
BL1, BL2 and BL31 (only on AArch64 platforms) are parts of TF-A, BL32 can be either in TF-A or outside (for example OP-TEE).
Because STM32 MPU platforms uses a dedicated ROM code, the BL1 boot stage is then removed. ROM code expects the BL2 to run at EL3 execution level. This mode is selected when the 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. In the BL2 stage, it is a reduced version of the Linux kernel one, with only the required devices used during boot. On AArch64 platforms, BL31 also has a dedicated device tree. They can be configured with STM32CubeMX.
2.1. Boot on AArch32 platform[edit | edit source]
TF-A loading steps:
- ROM code loads and calls BL2
- BL2 loads BL32
- BL2 loads BL33
- BL2 calls BL32
- BL32 calls BL33
2.2. Boot on AArch64 platform[edit | edit source]
TF-A loading steps:
- ROM code loads and calls BL2
- BL2 loads BL31
- BL2 loads BL32
- BL2 loads BL33
- BL2 calls BL31
- BL31 calls BL32
- BL31 calls BL33
3. Boot loader stages[edit | edit source]
3.1. BL1[edit | edit source]
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. As the STM32 MPU has 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[edit | edit source]
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: cryptographic peripheral, memory firewall, ...
- Storage
BL2 offers different features to load and authenticate images.
At the end of its execution, after having loaded BL32 and the next boot stage (BL33), BL2 jumps to BL31 (AArch64) or BL32 (AArch32).
3.3. BL31[edit | edit source]
On 64-bit Arm processors (AArch64), BL31 is the EL3 Runtime Software, also called Secure Monitor. More information can be found in TF-A documentation AArch64 BL31 chapter[8]. It handles secure monitor calls [5], and other standard service calls, like PSCI [4].
3.4. BL32[edit | edit source]
BL32 provides runtime secure services.
3.4.1. AArch32 platforms[edit | edit source]
On Armv7 architecture, the BL32 must embed a Secure Monitor as it will be executed in the same privilege level (PL1-SVC Secure). Before ecosystem release v5.0.0 , the minimal TF-A BL32 monitor support was provided. This is no more the case.
STMicroelectronics provides OP-TEE support that also embeds a secure monitor on Armv7. It can be replaced with a trusted OS or another trusted environment execution (TEE).
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 [5].
This code is in charge of standard service calls, like PSCI [4] or SCMI [6].
It also provides STMicroelectronics proprietary services to access some specific and limited secure peripherals (with secure access control).
3.4.2. AArch64 platforms[edit | edit source]
On AArch64 platforms, BL32 (OP-TEE) is in charge of runtime secure services, like SCMI [6].
4. References[edit | edit source]
- ↑ https://www.trustedfirmware.org/
- ↑ https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
- ↑ Trusted Firmware-A documentation
- ↑ Jump up to: 4.0 4.1 4.2 ARM Power State Coordination Interface
- ↑ Jump up to: 5.0 5.1 5.2 SMC Calling Convention (SMCCC)
- ↑ Jump up to: 6.0 6.1 6.2 Arm System Control and Management Interface
- ↑ Trusted Firmware-A Firmware Design
- ↑ TF-A documentation AArch64 BL31 chapter