Difference between revisions of "TF-A overview"

[quality revision] [unchecked revision]
m
m (Update readthedocs link)
Applicable for STM32MP13x lines, STM32MP15x lines

1 Trusted Firmware-A[edit]

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.[1]

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 [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:

  • The power state coordination interface (PSCI) [4]
  • SMC calling convention [5]
  • System control and management interface [6]

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

2 Architecture[edit]

The global architecture of TF-A is explained in the Trusted Firmware-A design [73] 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

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

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. It can be configured with STM32CubeMX.

Boot ATF.png

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[edit]

3.1 BL1[edit]

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]

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

3.3 BL32[edit]

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 [3] <ref name=TrustedFirmware> as: "A minimal AArch32 Secure Payload (SP-MIN) to demonstrate PSCI [4] 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.

Info white.png Information
STM32MP15 supports the SP-MIN but it is no more recommended. OP-TEE is the BL32 official solution.

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

4 References[edit]

  1. ↑ https://www.trustedfirmware.org/
  2. ↑ https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git
  3. ↑ 3.03.1 https://trustedfirmware-a.readthedocs.io/en/latest/ Trusted Firmware-A documentation
  4. ↑ 4.04.14.2 ARM Power State Coordination Interface
  5. ↑ 5.05.1 SMC Calling Convention (SMCCC)
  6. ↑ 6.06.1 Arm System Control and Management Interface
  7. ↑ https://trustedfirmware-a.readthedocs.io/en/latest/design/index.html 


<noinclude>{{ApplicableFor
|MPUs list=STM32MP13x, STM32MP15x
|MPUs checklist=STM32MP13x,STM32MP15x
}}</noinclude>

== 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>&reg;</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 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 license, and can be found on Linaro 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>https://trustedfirmware-a.readthedocs.io/en/latest/ {{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:
* The 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>

* System control and management interface <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.

== Architecture ==

The global architecture of TF-A is explained in the Trusted Firmware-A design <ref name=TrustedFirmware/>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), 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

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

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.

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 for Linux, U-Boot and TF-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. It can be configured with [[STM32CubeMX]].

[[File:Boot_ATF.png|center|upright=2]]

TF-A loading steps:
# ROM code loads and calls BL2
# BL2 loads 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 STM32 MPU. As the STM32 MPU 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 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

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

=== 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 <ref name=TrustedFirmware/> 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]] that also embeds a secure monitor on Armv7.
{{Info|STM32MP15 supports the SP-MIN but it is no more recommended. [[OP-TEE overview|OP-TEE]] is the BL32 official solution.}}

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


It also provides STMicroelectronics proprietary services to access some specific and limited secure peripherals (with secure access control).

==References==<references />

<noinclude>

[[Category:Trusted Firmware-A (BL2)| 01]]
[[Category:Trusted Firmware-A (SP-MIN)| 01]]
{{PublicationRequestId | 19292 (Previous 9178) | 2120-03-10 | PhilipS}}</noinclude>
Line 10: Line 10:
   
 
The code is open source, under a BSD-3-Clause license, and can be found on Linaro project page
  
The code is open source, under a BSD-3-Clause license, and can be found on Linaro 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>https://trustedfirmware-a.readthedocs.io/en/latest/</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:
Line 21: Line 21:
 
== Architecture ==
  
== Architecture ==
   
−
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.
 +
The global architecture of TF-A is explained in the Trusted Firmware-A design <ref name=TrustedFirmware/> document.
   
 
TF-A is divided into several binaries, each with a dedicated main role.<br>
  
TF-A is divided into several binaries, each with a dedicated main role.<br>
Line 69: Line 69:
 
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).
 
TF-A provides a minimal monitor implementation: SP-MIN.
  
TF-A provides a minimal monitor implementation: SP-MIN.
−
It is described in the TF-A functionality list <ref name=TrustedFirmware/> as:
 +
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."
   
Retrieved from "https://wiki.st.com/stm32mpu/index.php?title=TF-A_overview&oldid=84927"