Approved version. Approved on: 08:56, 25 September 2020
You are viewing an old version of this page. Return to the latest version.
Difference between revisions of "TF-A overview"
[quality revision] | [unchecked revision] |
m
|
m
|
/tmp/bshtmldiff/sfr_62bab82960f9/74110.html (No such file or directory)
== Trusted Firmware-A == [[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. Arm is transferring the Trusted Firmware project to be managed as an open-source project by Linaro.<ref>https://www.trustedfirmware.org/</ref> It is used as the first-stage boot loader (FSBL) on STM32 MPU platforms when using the [[Boot_chain_overview#STM32MP boot sequence|trusted boot chain]]. The code is open source, under a BSD-3-Clause licence, and can be found on github<ref>https://github.com/ARM-software/arm-trusted-firmware</ref>, including an up-to-date documentation about Trusted Firmware-A implementation <ref name=readmeTrustedFirmware>{{CodeSource | TF-A | readme.rst}}https://trustedfirmware-a.readthedocs.io/en/latest/</ref>. Trusted Firmware-A also implements a secure monitor with various Arm interface standards: * The power state coordination interface (PSCI) <ref name=psci>http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf</ref> * Trusted board boot requirements (TBBR) <ref>Arm DEN0006C-1https://developer.arm.com/documentation/den0006/d</ref> * SMC calling convention <ref name=smc>http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf </ref> * System control and management interface <ref>http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf </ref> Trusted Firmware-A is usually shortened to TF-A. == Architecture == The global architecture of TF-A is explained in the Trusted Firmware-A design <ref>{{CodeSource | TF-A | docs/firmware-design.rst}}https://trustedfirmware-a.readthedocs.io/en/latest/design/index.html</ref> document. TF-A is divided into several binaries, each with a dedicated main role.<br> For 32-bit Arm processors (AArch32), it trusted boot is divided into four stepsstages (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. BL1 is now optional, and can be removed by enabling the compilation flag: BL2_AT_EL3. It is then removed for the STM32MP1, as all BL1 tasks are done by Because STM32MP platform use a dedicated [[:Category:ROM code|ROM code]], BL1 boot stage is then removed. [[:Category:ROM code|ROM code]], or 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 overview|U-Boot]] by default. TF-A can manage its configuration with a [[STM32MP15_device_tree#Device tree structure for Linux, U-Boot and TF-A|device tree]], as this is the case on STM32MP1. It is a reduced version of the Linux kernel one, with only the devices used during boot. It can be configured with [[STM32CubeMX]]. In STMicroelectronics' implementation, the 2 binaries, BL2 and BL32, and the its device tree are putlinked together in a single binary, to be loaded at once to the SYSRAM by the ROM code. [[File:Boot_ATF.png|center|link=]] [[File:Boot_ATF_legend.png|center|link=]] TF-A loading steps: # ROM code loads TF-A binary and calls BL2 # BL2 prepares BL32 # BL2 loads BL33 # BL2 calls BL32 # 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 [[:Category:ROM code|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.<br> 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 (linked to boot peripheral). The boot peripheral has to be initialized.<br> 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, For the memory programming use case (see [[STM32CubeProgrammer]] for more details. BL2 also integrates image verification and authentication. Authentication is achieved by calling [[STM32MP15 ROM code overview|BootROM]] verification services. ): * USB ([[OTG internal peripheral]]) * UART([[USART internal peripheral]]) 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 <ref name=readmeTrustedFirmware/> as: "A minimal AArch32 Secure Payload (SP-MIN) to demonstrate PSCI <ref name=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 overview|OP-TEE]]. Both solutions (SP-MIN or OP-TEE) are supported by STMicroelectronics for STM32MP1STM32MP15. 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 <ref name=smc/>. This code is in charge of standard service calls, like PSCI <ref name=psci/>.<br/> 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==<references /> <noinclude> [[Category:Trusted Firmware-A (TF-A)| 01]] [[Category:Trusted Firmware-A (SP-MIN)| 01]] {{PublicationRequestId | 9178 | 2018-10-24 | PhilipS}}</noinclude>
Line 6: | Line 6: | ||
The code is open source, under a BSD-3-Clause licence, and can be found on github |
The code is open source, under a BSD-3-Clause licence, and can be found on github |
||
− | <ref>https://github.com/ARM-software/arm-trusted-firmware</ref>, including an up-to-date documentation about Trusted Firmware-A implementation <ref name= |
+ | <ref>https://github.com/ARM-software/arm-trusted-firmware</ref>, including an up-to-date documentation about Trusted Firmware-A implementation <ref name=TrustedFirmware>https://trustedfirmware-a.readthedocs.io/en/latest/</ref>. |
Trusted Firmware-A also implements a secure monitor with various Arm interface standards: |
Trusted Firmware-A also implements a secure monitor with various Arm interface standards: |
||
* The power state coordination interface (PSCI) <ref name=psci>http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf</ref> |
* The power state coordination interface (PSCI) <ref name=psci>http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf</ref> |
||
− | * Trusted board boot requirements (TBBR) <ref> |
+ | * Trusted board boot requirements (TBBR) <ref>https://developer.arm.com/documentation/den0006/d</ref> |
* SMC calling convention <ref name=smc>http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf </ref> |
* SMC calling convention <ref name=smc>http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf </ref> |
||
* System control and management interface <ref>http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf </ref> |
* System control and management interface <ref>http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf </ref> |
||
Line 18: | Line 18: | ||
== Architecture == |
== Architecture == |
||
− | The global architecture of TF-A is explained in the Trusted Firmware-A design <ref> |
+ | The global architecture of TF-A is explained in the Trusted Firmware-A design <ref>https://trustedfirmware-a.readthedocs.io/en/latest/design/index.html</ref> document. |
− | TF-A is divided into several binaries, each with a dedicated main role. For 32-bit Arm processors (AArch32), |
+ | TF-A is divided into several binaries, each with a dedicated main role.<br>
|
+ | 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 1 (BL1) application processor trusted ROM |
||
* Boot loader stage 2 (BL2) trusted boot firmware |
* Boot loader stage 2 (BL2) trusted boot firmware |
||
Line 28: | Line 29: | ||
BL1, BL2 and BL32 are parts of TF-A. |
BL1, BL2 and BL32 are parts of TF-A. |
||
− | BL1 is |
+ |
Because STM32MP platform use a dedicated [[:Category:ROM code|ROM code]], BL1 boot stage is then removed. [[:Category:ROM code|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 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. |
||
Line 34: | Line 35: | ||
TF-A can manage its configuration with a [[STM32MP15_device_tree#Device tree structure for Linux, U-Boot and TF-A|device tree]], as this is the case on STM32MP1. 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 can manage its configuration with a [[STM32MP15_device_tree#Device tree structure for Linux, U-Boot and TF-A|device tree]], as this is the case on STM32MP1. It is a reduced version of the Linux kernel one, with only the devices used during boot. It can be configured with [[STM32CubeMX]]. |
||
− | In STMicroelectronics' implementation, the 2 binaries, BL2 and |
+ | In STMicroelectronics' implementation, the 2 binaries, BL2 and its device tree are linked together in a single binary, to be loaded at once to the SYSRAM by the ROM code. |
[[File:Boot_ATF.png|center|link=]] |
[[File:Boot_ATF.png|center|link=]] |
||
Line 51: | Line 52: | ||
=== BL1 === |
=== BL1 === |
||
BL1 is the first stage executed, and is designed to act as ROM code; it is loaded and executed in internal RAM. |
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 |
+ | It is not used for the STM32MP1. As the STM32MP1 has its own proprietary [[:Category:ROM code|ROM code]], this part can be removed and BL2 is then the first TF-A binary to be executed. |
=== BL2 === |
=== BL2 === |
||
− | 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. |
To achieve this role, BL2 has to initialize all the required peripherals. |
||
Line 60: | Line 61: | ||
For the STM32MP15, these security peripherals are: |
For the STM32MP15, these security peripherals are: |
||
* boot and security, and OTP control ([[BSEC internal peripheral]]) |
* boot and security, and OTP control ([[BSEC internal peripheral]]) |
||
− | |||
* TrustZone address space controller for DDR ([[TZC internal peripheral]]) |
* TrustZone address space controller for DDR ([[TZC internal peripheral]]) |
||
− | BL2 is also in charge of initializing the DDR and clock tree. |
+ | BL2 is also in charge of initializing the DDR and clock tree (linked to boot peripheral). |
The boot peripheral has to be initialized.<br> |
The boot peripheral has to be initialized.<br> |
||
Line 71: | Line 71: | ||
* NAND via the [[FMC internal peripheral]] |
* NAND via the [[FMC internal peripheral]] |
||
* NOR via the [[QUADSPI internal peripheral]] |
* NOR via the [[QUADSPI internal peripheral]] |
||
− | + | For the memory programming use case (see [[STM32CubeProgrammer]] for more details): |
|
− | USB ([[OTG internal peripheral]]) |
+ |
* USB ([[OTG internal peripheral]]) |
− | + |
* UART([[USART internal peripheral]]) |
|
− | |||
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 BL32. |
||
Line 80: | Line 79: | ||
=== BL32 === |
=== BL32 === |
||
BL32 provides runtime secure services. In TF-A, the BL32 default implementation is SP-MIN solution. |
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 <ref name= |
+ | It is described in the TF-A functionality list <ref name=TrustedFirmware/> as: |
"A minimal AArch32 Secure Payload (SP-MIN) to demonstrate PSCI <ref name=psci/> library integration with AArch32 EL3 Runtime Software." |
"A minimal AArch32 Secure Payload (SP-MIN) to demonstrate PSCI <ref name=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 overview|OP-TEE]]. |
This minimal implementation can be replaced with a trusted OS or trusted environment execution (TEE), such as [[OP-TEE overview|OP-TEE]]. |
||
− | Both solutions (SP-MIN or OP-TEE) are supported by STMicroelectronics for |
+ | 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 <ref name=smc/>. |
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 <ref name=smc/>. |
||
Line 90: | Line 89: | ||
This code is in charge of standard service calls, like PSCI <ref name=psci/>.<br/> |
This code is in charge of standard service calls, like PSCI <ref name=psci/>.<br/> |
||
− | It also provides STMicroelectronics dedicated services, to access secure peripherals. On the |
+ | 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]] or [[BSEC internal peripheral]]. |
==References== |
==References== |