The TrustZone for Cortex-M is a security extension for Armv8-M architecture that is optimized for ultra-low power embedded applications. It enables software security domains that restrict access to secure memory and I/O only for trusted software.
TrustZone for Armv8-M:
Notations
This manual uses the following notations to identify functions and hardware resources that are related to TrustZone for Armv8-M:
TZ
or __TZ
indicates a function that is available only in Armv8-M TrustZone enabled devices._NS
indicates a hardware resource that belongs to the Non-secure state._S
indicates a hardware resource that belongs to the Secure state.An Armv8-M TrustZone enabled device has restricted access for data, code, and I/O access to trusted software that runs in the Secure state. Typical applications are secure IoT nodes, firmware IP protection, or multi-party embedded software deployments.
The figure Simplified Use Case shows and embedded application that is split into a User Project (executed in Non-secure state) and a Firmware Project (executed in Secure state).
Program execution in the Secure state is further protected by TrustZone hardware from software failures.
For example, an Armv8-M system may implement two independent SYSTICK timers which allows to stop code execution in Non-secure state in case of timing violations. Also function pointer callbacks from Secure state to Non-secure state protected by a special CPU instruction and the address bit 0 which prevents anciently executing code in Non-secure state.
This CMSIS-RTX contains the following program examples that show the usage of TrustZone for Armv8-M on Cortex-M33 devices:
Example | Description |
---|---|
TrustZone for Armv8-M No RTOS | bare-metal secure/non-secure programming without RTOS (shows the Simplified Use Case). |
TrustZone for Armv8-M RTOS | secure/non-secure RTOS example with thread context management |
TrustZone for Armv8-M RTOS Security Tests | secure/non-secure RTOS example with security test cases and system recovery |
Other sample application that reflects this Simplified Use Case is the Armv8MBL Secure/Non-Secure example that is available in the Software Pack Keil - Arm V2M-MPS2 Board Support PACK for Cortex-M System Design Kit Devices (Keil:V2M-MPS2_CMx_BSP.1.2.0.pack or higher).
The figure Secure Memory Map shows the memory view for the Secure state. In the Secure state all memory and peripherals can be accessed. The System Control and Debug area provides access to secure peripherals and non-secure peripherals that are mirrored at a memory alias.
The secure peripherals are only accessible during program execution in Secure state. The Secure Attribute Unit (SAU) configures the non-secure memory, peripheral, and interrupt access. Also available are a secure MPU (memory protection unit), secure SCB (system control block), and secure SysTick timer.
The system supports two separate interrupt vector tables for secure and non-secure code execution.
This interrupt assignment is controlled during Secure state code execution via the NVIC (nested vector interrupt controller).
The figure Non-Secure Memory Map shows the memory view for the Non-secure state. This memory view is identical to the traditional Cortex-M memory map. Access to any secure memory or peripheral space triggers the secure exception that executes a handler in Secure state.
The TrustZone setup: partition_<Device>.h defines the initial setup of the Non-Secure Memory Map during system start in the Secure state (refer to functions SystemInit and TZ_SAU_Setup).
The figure Registers shows the register view of the Armv8-M system with TrustZone. As the general purpose registers are can be accessed from any state (secure or non-secure), function calls between the states use these registers for parameter and return values.
The register R13 is the stack pointer alias, and the actual stack pointer (PSP_NS, MSP_NS, PSP_S, MSP_S) accessed depends on state (Secure or Non-secure) and mode (handler=exception/interrupt execution or thread=normal code execution).
In Armv8-M Mainline, each stack pointer has a limit register (PSPLIM_NS, MSPLIM_NS, PSPLIM_S, MSPLIM_S) that traps stack overflows with the UsageFault exception (register UFSR bit STKOF=1).
An Armv8-M system with TrustZone has an independent CONTROL register for each state (Secure or Non-secure).
The interrupt/exception control registers (PRIMASK, FAULTMASK, BASEPRI) are banked between the states (Secure or Non-secure), however the interrupt priority for the Non-Secure state can be lowered (SCB_AIRCR register bit PRIS) so that secure interrupts have always higher priority.
The core registers of the current state (Secure or Non-secure) are accessed using the standard Core Register Access functions. In Secure state all non-secure registers are accessible using the Core Register Access Functions related to TrustZone for Armv8-M.
CMSIS-Core Stack Sealing Support Functions provide standard interface for implementing the Secure Stack Sealing technique recommended for mitigating some security vulnerabilities on Armv8-M systems with TrustZone.
startup_Device.c Template File demonstrates how this functionality can be used in a device startup file.
Stack Sealing also requires an application project to have a linker script that explicitly reserves 8 bytes for the stack seal on top of the secure main stack. Linker files provided with Device Examples for Armv8-M cores demonstrate how this can be implemented. For example see .\Device\ARM\ARMCM33\Source\ARM\ARMCM33_ac6.sct.
To learn more about the stack sealing implementation in CMSIS projects for Armv8-M devices, refer to Application Note 335.
The CMSIS-Core files are extended by the header files TrustZone setup: partition_<Device>.h and Region/ISR setup: partition_gen.h :
Note
- Refer to Using CMSIS-Core for a general description of the CMSIS-Core (Cortex-M) files.
To provide a consistent RTOS thread context management for Armv8-M TrustZone across the various real-time operating systems (RTOS), the CMSIS-Core (Cortex-M) includes header file tz_context.h with API definitions.
A non-secure application which uses an RTOS and calls secure library modules requires the management of the secure stack space. Since secure state registers cannot be accessed by the RTOS that runs in non-secure state secure functions implement the thread context switch.
As the non-secure state and secure state parts of an application are separated, the API for managing the secure stack space should be standardized. Otherwise the secure library modules would force the non-secure state application to use a matching RTOS implementation.
To allocate the context memory for threads, an RTOS kernel that runs in non-secure state calls the interface functions defined by the header file tz_context.h. The TZ Context functions themselves are part of the secure state application. An minimum implementation is provided as part of RTOS2 and should handle the secure stack for the thread execution. However it is also possible to implement the context memory management system with additional features such as access control to secure state memory regions using an MPU.
The API functions of TZ Context are described in the chapter API Reference under TrustZone for Armv8-M/v8.1-M - RTOS Context Management.
CMSIS-Core provides a template implementation of TZ Contenxt in CMSIS\Core\Template\ARMv8-M\tz_context.c
file.
Refer to Program Examples for RTOS examples that demonstrate how to use the RTOS Thread Context Management.