Trustzone environment

Revision as of 07:02, 25 May 2022 by Lionel Debieve (talk | contribs) (Created page with "== Article purpose == The purpose of this article is to explain how the TrustZone execution context is used for on an STM32 MPU-based platform.<br> == Introduction == The STM...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

1 Article purpose[edit]

The purpose of this article is to explain how the TrustZone execution context is used for on an STM32 MPU-based platform.

2 Introduction[edit]

The STM32 MPU is based on the Arm® Cortex®-A core, which is using the Arm® TrustZone[1] architecture that enables context isolation: the normal world holds the applications whereas the secure world isolates all the trusted applications and core secure services so that they can safely manipulate platform secret data. The MPU includes Firewall mechanisms that allow the secure world to forbid read/write accesses from the normal world to given peripherals.

Arm-v7A defines PL0, PL1 and PL2 privilege levels:

  • PL0 is the lowest software execution level (unprivileged calls allowed for applications).
  • PL1 is the execution level for the OS.
  • PL1 (secure) is also the privilege level for secure monitor execution, to switch from the secure to the normal world.
  • PL2 is dedicated to the hypervisor (only non-secure).

Trustzone.png

The normal world is used to run rich OSs such as Linux Kernel and its applications framework.
The secure world runs a TEE as secure OS (i.e. OP-TEE OS) including a secure monitor.

The TrustZone environment is a complete system solution that is not limited to the Cortex context. It provides a bus and peripheral infrastructure to the MPU in order to ensure that the secure world relies on a completely secured pipe when it controls a secure peripheral. The assignment of the peripherals to a given world is done thanks to a firewall mechanism, which is set up during the secure world initialization.

Dedicated secure and normal contexts also impact the debugging facilities: depending on the targeted user, the debug can be opened to both worlds (e.g. for a secure aware developer), to normal world only (for a Linux® developer) or completely closed (for the end user). This is achieved by configuring the Debug control.

Some internal or external peripherals can be used by the secure world to support cryptographic operations. Refer to security peripherals for an introduction.

3 References[edit]