Overview and Summary of ARMv8-M TrustZone

First, let’s take a look at a software architecture diagram:

The concept of TrustZone technology is not new. This technology has been used in Arm Cortex-A series processors for many years and has now expanded to cover Armv8-M processors.

At a high level, the concept of TrustZone technology in Armv8-M is similar to that in Arm Cortex-A processors. The processor has secure and non-secure states, and non-secure software can only access non-secure memory. The technology of Armv8-M is designed with small, energy-efficient systems in mind. Unlike the TrustZone technology in Cortex-A processors, the Secure and Normal worlds of Armv8-M are memory-mapped, with transitions occurring automatically in the exception handling code.

There are several differences in the TrustZone technology supported by Armv8-M compared to Armv8-A:

• Armv8-M’s TrustZone technology supports multiple secure entry points, while in the Cortex-A processor’s TrustZone technology, the Secure Monitor handler is the only entry point.

• It can handle non-secure interrupts while executing in secure state, which is crucial for many real-time applications in microcontrollers where deterministic behavior and low interrupt latency are important requirements. The ability to handle interrupt requests while running secure code is essential.

• By allowing a shared register set between secure and non-secure states, the power consumption achieved by Armv8-M can be similar to that of Armv6-M or Armv7-M.

• The low overhead of state switching allows secure and non-secure software to interact frequently, which is common in cases where secure firmware contains software libraries like GUI firmware or communication protocol stacks.

In designs with Armv8-M architecture security extensions, components critical to system security can be placed in the secure world. These critical components include:

• Secure bootloader.

• Keys.

• Flash programming support.

• High value assets.

The term security can have many different meanings in embedded system design. In most embedded systems, security can include but is not limited to:

• Communication protection that prevents unauthorized parties from seeing or intercepting data transmissions and may involve other technologies such as cryptography.
• Data protection that prevents unauthorized parties from accessing sensitive data stored within the device.
• Firmware protection that prevents on-chip firmware from being reverse-engineered.
• Runtime protection that prevents malicious intentional failures of critical operations.
• Tamper protection which is needed in many security-sensitive products to prevent the operation or protection mechanisms of the device from being compromised. TrustZone technology can directly address some of the security requirements of embedded systems:
• Data protection where sensitive data can be stored in secure memory space and can only be accessed by secure software. Non-secure software can only access secure APIs for services to the non-secure domain and only after security checks or authentication.
• Firmware protection where pre-loaded firmware can be stored in secure memory to prevent it from being reverse-engineered and subjected to malicious attacks. Armv8-M’s TrustZone technology can also be used in conjunction with additional protection technologies. For example, device-level read-out protection, a technology commonly used in the industry today, can be combined with Armv8-M’s TrustZone technology to protect the final firmware product.

• Secure boot mechanisms instill confidence in the platform as it always boots from secure memory.

TrustZone technology can also be used with additional protection features in next-generation microcontrollers used for Internet of Things (IoT) products. For example, microcontrollers developed for IoT applications can include a range of security features.

The use of TrustZone technology helps ensure that all these features can only be accessed using APIs with valid entry points, as shown in the following diagram:

By using TrustZone technology to protect these security features, designers can:

• Prevent untrusted applications from directly accessing security-critical resources.
• Ensure that Flash images are reprogrammed only after validation and checks.
• Prevent firmware from being reverse-engineered.

• Provide software-level protection for storing confidential information.

Security of Wireless Communication Interfaces

In other application scenarios, such as wireless SoCs with certified built-in radio stacks, TrustZone technology can protect standardized operations such as wireless communication behaviors.

TrustZone technology can ensure that customer-defined applications do not compromise the certification, as shown in the following diagram.

About Reset

• If security extensions are implemented, memory regions marked as secure and other critical resources can only be accessed when the PE is executing in secure state.

• If security extensions are implemented, during Cold reset and Warm reset, the PE will enter Secure state.

• If security extensions are implemented, during Cold reset and Warm reset, the PE will enter Non-Secure state.

About Banked

After implementing security extensions, the following registers are banked by security:

• R13 (SP) in general registers

• MASK registers (PRIMASK, BASEPRI, FAULTMASK), CONTROL register, stack pointer limit registers (MSPLIM, PSPLIM) in special registers

• System Control Space (SCS)

MSR/MRS Instruction Encoding

MRS andMSR instruction encoding’s bit[7] indicates which set of registers is being operated on (Secure or Non-Secure).

Switching of Security States

There are two ways to switch security states:

• Direct function calls and returns (non-secure callable)

• Entry and exit of exceptions/interrupts

If security extensions are implemented, the 4GB memory space will be divided into secure and non-secure memory regions.

The secure memory space is further divided into two types: secure (S) and non-secure callable (NSC: Non-secure Callable).

NSC is a special type of secure memory. This type of memory is allowed by the Armv8-M processor to save SG instructions, enabling software to transition from non-secure to secure state.

By restricting the functionality of SG instructions to NSC memory, secure software creators do not inadvertently include SG instructions or data sharing encoding values in normal secure memory, containing NSC memory locations.

Typically, the NSC memory region contains a table of small branch jumps (entry points). To prevent non-secure applications from branching to invalid entry points, there are Secure Gateway (SG) instructions.

When a non-secure program calls a function on the secure side:

• The first instruction in the API must be the SG instruction.

• The SG instruction must be located in the NSC region defined by the Security Attribution Unit (SAU) or Implementation Defined Attribution Unit (IDAU).

• SAU: Security Attribution Unit

• IDAU: Implementation Defined Attribution Unit

SAU is disabled during reset

If SAU is disabled, and there is no IDAU in the system, and since the default state during reset is Secure Security State, the system will be unable to switch to Non-secure state, and all operations switching to non-secure Security state will generate Fault errors.

After SAU is enabled:

• Anything outside the SAU region is considered secure memory.

• SAU_RLAR.NSC=0 indicates non-secure memory.

• SAU_RLAR.NSC=1 indicates NSC memory.