Summary and Introduction of ARMv8-M (Cortex-M) TrustZone

First, let’s 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 been extended to cover Armv8-M processors.

At a higher level, the concept of TrustZone technology in Armv8-M is similar to that in Arm Cortex-A processors. The processors have secure and non-secure states, where 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, and the transitions occur automatically in exception handling code.

The TrustZone technology supported by Armv8-M and Armv8-A has the following differences:

• The TrustZone technology of Armv8-M supports multiple security entry points, while in the TrustZone technology of Cortex-A processors, the Secure Monitor handler is the only entry point.

• Interrupts can still be handled while executing in secure state, which is important for many microcontroller applications with real-time processing capabilities, where deterministic behavior and low interrupt latency are critical requirements. The ability to handle interrupt requests while running secure code is essential.

• By allowing the sharing of register groups between secure and non-secure states, Armv8-M achieves power consumption similar to Armv6-M or Armv7-M.

• Low overhead for state switching allows frequent interactions between secure and non-secure software, which is common when secure firmware contains software libraries such as GUI firmware or communication protocol stacks.

In designs with Armv8-M architecture security extensions, components that are critical to system security can be placed in the secure world. These key 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 data transmissions from being viewed or intercepted by unauthorized parties, and may include other technologies such as cryptography.
• Data protection that prevents unauthorized parties from accessing secret data stored within the device.
• Firmware protection that prevents on-chip firmware from being reverse-engineered.
• Runtime protection that prevents critical operations from malicious intentional failures.
• Tamper protection that is required in many security-sensitive products to prevent the operation or protective mechanisms of the device from being compromised. TrustZone technology can directly address some of the security requirements of embedded systems:
• Data protection 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 that provide services to the non-secure domain, and only after security checks or authentication.
• Firmware protection pre-loaded firmware can be stored in secure memory to prevent it from being reverse-engineered and subjected to malicious attacks. The TrustZone technology of Armv8-M 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 used together with the TrustZone technology of Armv8-M to protect the final firmware product.

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

TrustZone technology can also be used in conjunction with additional protection features used in next-generation microcontrollers for IoT (Internet of Things) 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 verification and checks.
• Prevent firmware from being reverse-engineered.

• Provide software-level protection for storing confidential information.

Security of Wireless Communication Interfaces

In some 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 invalidate 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 executes in secure state.

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

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

About Banked

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

• R13 (SP) in general registers.

• Special registers: MASK registers (PRIMASK, BASEPRI, FAULTMASK), CONTROL register, stack pointer limit registers (MSPLIM, PSPLIM).

• System Control Space (SCS).

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 partitioned into secure and non-secure memory regions.

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 store SG instructions, allowing software to switch from non-secure state to secure state.

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

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

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 area defined by the Security Attribution Unit (SAU) or Implementation Defined Attribution Unit (IDAU).

• SAU: Security Attribution Unit.

• IDAU: Implementation Defined Attribution Unit.

When reset, SAU is disabled.

If SAU is disabled, and the system does not include IDAU, and since the default state during reset is Secure Security State, the system will not be able to switch to Non-secure state, and all operations to switch to non-secure Security state will produce Fault errors.

After SAU is enabled:

• Anything not within the SAU region is considered secure memory.

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

• SAU_RLAR.NSC=1 indicates NSC memory.