Exceptionally, this wiki is under maintenance.

You can continue to browse it to discover the STM32MP1 series and associated ecosystems (STM32 boards, embedded software, development tools, trace & debug tools...) but contributors can not improve their favorite articles, during phase.

Thank you for your understanding.

Trustzone environment

Revision as of 18:25, 13 November 2022 by Registered User

1 Article purpose[edit]

This article explains how the Arm® 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).


The normal world is used to run rich OSs such as the Linux® kernel and its applications framework.
The secure world runs a TEE as the secure OS (for example 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 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 through 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 (for instance for a secure-aware developer), to the 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]