SAM L11 TrustZone® Implementation

ARM® TrustZone® for ARMv8-M Introduction

The central security element for the Microchip SAM L11 microcontroller (MCU) is the implementation of the TrustZone for an ARMv8-M device. The TrustZone technology is a System-on-Chip (SoC) and MCU system-wide approach to security that enables Secure and Non-Secure application code to run on a single MCU. TrustZone for an ARMv8-M device is based on specific hardware that is implemented in the Cortex-M23 core, which is combined with a dedicated secure instruction set. It enables the creation of multiple software security domains that restrict access to selected memory, peripherals, and I/O to trusted software without compromising the system performances. The main goal of the TrustZone for an ARMv8-M device is to simplify security assessment of a deeply embedded device.

The principle behind the TrustZone for an ARMv8-M embedded software application is illustrated in the figure below.


In the SAM L11 Cortex-M23 Core implementation, security management is done using the Implementation Defined Attribution Unit (IDAU). The IDAU interface controls the access to the execution of specific instructions which are based on the current core security state and the address of the instruction. The figure below illustrates the Core/Debugger access verification, performed by the system prior to allowing access to a specific memory region.


Thanks to this implementation, a simple function call or an interrupt process results in a branch to a specific security state as illustrated in the figure below. This allows for efficient calling by avoiding any code and execution overhead.


Memory Security Attribution

To differentiate and isolate the Secure code from the Non-Secure code, the SAM L11 memory is divided into ten memory regions as shown in the figure below. Each region size can be configured using dedicated NVM fuses, such as:

  • Boot Secure (BS)
  • Boot Non-Secure Callable (BNSC)
  • Boot Protection (BOOTPROT)
  • Application Secure (AS)
  • Application Non-Secure Callable (ANSC)
  • Data Flash Secure (DS)
  • RS (SRAM Secure)

Each memory region is preconfigured in the hardware with one of the following attributes:

  • Non-Secure (NS): Non-Secure addresses are used for memory and peripherals, which are accessible by all software running on the device.
  • Secure (S): Secure addresses are used for memory and peripherals, which are accessible only by Secure software.
  • Non-Secure Callable (NSC): NSC is a special type of Secure memory location. It enables software transition from a Non-Secure to a Secure state.

The security attribute of each region will define the security state of the code stored in this region.

Secure and Non-Secure Function Call Mechanism

To prevent Secure code and data from being accessed from a Non-Secure state, the Secure code must meet several requirements. The responsibility for meeting these requirements is shared between the MCU architecture, software architecture, and the toolchain configuration. At the core level, a set of Secure instructions dedicated to ARMv8-M devices are used to preserve and protect the secure register values during the CPU security state transition.

  • Secure Gateway (SG): Used for switching from a Non-Secure to a Secure state at the first instruction of a Secure entry point.
  • Branch with exchange to Non-Secure state (BXNS): Used by the Secure software to branch, or return to the Non-Secure program.
  • Branch with link and exchange to Non-Secure state (BLXNS): Used by the Secure software to call the Non-Secure functions.

At the toolchain level, a ‘C’ language Extension (CMSE) provided by ARM must be used to ensure the use of ARMv8-M Secure instruction at the software architecture level. Specific Secure and Non-Secure function call mechanisms must be used to ensure security.

Non-Secure Callable APIs

When working with TrustZone for ARMv8-M, the application developer can define a set of Non-Secure callable APIs which can be used to access the Secure code from the Non-Secure world. These APIs, known as Secure Gateways (SG) or veneers are in charge of the CPU Security state switch and allow the decoupling of Secure entry points from the rest of the Secure code. Therefore, limiting the amount of code that can potentially be accessed by the Non-Secure state. SG is expected to be placed in NSC memory regions, which are executable only when the CPU is in Non-Secure state. The rest of the Secure code is expected to be placed in the Secure memory regions which are not accessible when the CPU is in Non-Secure state, see figure below.


Using Non-Secure callable APIs require the use of specific Cortex-M23 instructions that ensure security during the core security state switching. A direct API function call from the Non-Secure to the Secure software entry points is allowed only if the first instruction of the entry point is an SG and is in a Non-Secure callable memory location. The use of the special instructions (BXNS and BLXNS) are also required to branch to Non-Secure code.

The following code illustrates Secure function and its SG APIs declaration and definition using ARM GCC toolchain with a C language Extension (CMSE).


Veneer.c (linked in the NSC memory region of the device):

Secure_function.c (linked in the secure memory region of the device):

Non-Secure Software Callbacks

The Secure code can define and use software callbacks to execute functions from the Non-Secure world. This is a consequence of separating Secure and Non-Secure code into separate executable files. The following figure shows the software callback approach.


The management of callback functions can be performed using BLXNS instruction. The following figure illustrates the Non-Secure callback mechanism


The definition of Non-Secure software callback is done through a pointer to Non-Secure code location. If not correctly checked in the Secure application, wrong use of pointers can lead to a security weakness that enables execution of any Secure functions by the Non-Secure code. To overcome this disadvantage, a set of CMSE functions based on the new Cortex-M23 Test Target (TT) instructions is provided.

Security State and Call Mismatch

Any attempts to access Secure regions from the Non-Secure code or a mismatch between the code that is executed and the security state of the system results in a HardFault exception as shown in the following figure:


Secure and Non-Secure Interrupt Handling

The Cortex-M23 (ARMv8-M architecture) uses the same exception stacking mechanism as the ARMv7-M architecture, where a subset of core registers is stored automatically into the stack (hardware context saving). This permits immediate execution of the interrupt handler without the need to perform a context save in the software. ARMv8-M extends this mechanism to provide enhanced security based on two different stack pointers (a Secure stack pointer and a Non-Secure stack pointer). According to the priority settings configured in the Nested Vector Interrupt Controller (NVIC), Secure code execution can interrupt Non-Secure code execution, and Non-Secure code can interrupt Secure code execution.

The NVIC registers at the core level are duplicated. This allows two vector table definitions, one for Secure and another for Non-Secure. At a product start-up, all interrupts are mapped by default to the Secure world (Secure vector table). Specific CMSIS functions accessible in the Secure world, allocate each interrupt vector to a Non-Secure handler (declared in Non-Secure vector table). As illustrated in the figure below, if the Secure code is running when a higher priority Non-Secure interrupt arrives, the core pushes all its register content into a dedicated Secure stack. Registers are then zeroed automatically to prevent any information being read, and the core executes the Non-Secure exception handler. When the Non-Secure handler execution is finished, the hardware recovers all the registers from the Secure stack automatically.

This mechanism is managed in hardware and does not require any software intervention. This allows a Secure handover from running Secure code to a Non-Secure interrupt handler and returning to running Secure code.

© 2024 Microchip Technology, Inc.
Notice: ARM and Cortex are the registered trademarks of ARM Limited in the EU and other countries.
Information contained on this site regarding device applications and the like is provided only for your convenience and may be superseded by updates. It is your responsibility to ensure that your application meets with your specifications. MICROCHIP MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WHETHER EXPRESS OR IMPLIED, WRITTEN OR ORAL, STATUTORY OR OTHERWISE, RELATED TO THE INFORMATION, INCLUDING BUT NOT LIMITED TO ITS CONDITION, QUALITY, PERFORMANCE, MERCHANTABILITY OR FITNESS FOR PURPOSE. Microchip disclaims all liability arising from this information and its use. Use of Microchip devices in life support and/or safety applications is entirely at the buyer's risk, and the buyer agrees to defend, indemnify and hold harmless Microchip from any and all damages, claims, suits, or expenses resulting from such use. No licenses are conveyed, implicitly or otherwise, under any Microchip intellectual property rights.