Difference between revisions of "TF-A overview"

[quality revision] [unchecked revision]
m
m

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. Arm is transferring the Trusted Firmware project to be managed as an open-source project 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 licence, and can be found on github [2], including an up-to-date documentation about Trusted Firmware-A implementation [3].

Trusted Firmware-A also implements a secure monitor with various Arm interface standards:

  • The power state coordination interface (PSCI) [4]
  • Trusted board boot requirements (TBBR) [5]
  • SMC calling convention [6]
  • System control and management interface [7]

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 [8] document.

TF-A is divided into several binaries, each with a dedicated main role.
For 32-bit Arm processors (AArch32), it trusted boot is divided into four steps 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 platform use a dedicated ROM code, BL1 is now optional, and can be removed by enabling the compilation flag: BL2boot stage is then removed. ROM code expect the BL2 to run at EL3 execution level. This mode is selected when BL2_AT_EL3 . It is then removed for the STM32MP1, as all BL1 tasks are done by ROM code, or BL2build 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. 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 put linked together in a single binary, to be loaded at once to the SYSRAM by the ROM code.

Boot ATF.png
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

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

3.2 BL2[edit]

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:

BL2 is also in charge of initializing the DDR and clock tree (linked to boot peripheral).

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

For the memory programming use case (see STM32CubeProgrammer for more details):

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

3.3 BL32[edit]

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 [3] 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. 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 [6].

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

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.

4 References[edit]


== 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. 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=readme>{{CodeSource | TF-A | readme.rst}}</ref>.
+
<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>Arm DEN0006C-1</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>{{CodeSource | TF-A | docs/firmware-design.rst}}</ref> document.
+
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), it is divided into four steps (in order of execution):
+
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 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 [[:Category:ROM code|ROM code]], or BL2.
+
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 BL32, and the device tree are put together in a single binary, to be loaded at once to the SYSRAM by the ROM code.
+
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 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.
+
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 (trusted boot firmware) is in charge of loading the next-stage images (secure and non secure).
+
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]])
* extended TrustZone protection controller ([[ETZPC 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]]) or UART([[USART internal peripheral]]) are used when Flashing, see [[STM32CubeProgrammer]] for more details.
+
* USB ([[OTG internal peripheral]])
 
+
* UART([[USART internal peripheral]])
BL2 also integrates image verification and authentication. Authentication is achieved by calling [[STM32MP15 ROM code overview|BootROM]] verification services.
 
   
 
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=readme/> 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."
   
 
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 STM32MP1.
+
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 STM32MP1, these services are used to access [[RCC internal peripheral]], [[PWR internal peripheral]], [[RTC internal peripheral]] or [[BSEC internal peripheral]].
+
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==