ARM TrustZone Architecture Explained

1. The Core Concept: Two Worlds, One Processor

At its heart, ARM TrustZone is a hardware security extension that partitions a single processor and the entire System-on-Chip (SoC) into two isolated environments:

• The Normal World: Also called the Rich Execution Environment (REE). This is where a complex, feature-rich OS like Linux or Android, along with its applications, typically runs. Due to its size and complexity, it has a larger "attack surface" and is considered less trusted.
• The Secure World: Also called the Trusted Execution Environment (TEE). This is a smaller, more secure environment designed to run a minimal, highly-vetted secure OS and trusted applications that handle sensitive data and operations.

The goal is to provide a hardware-enforced "firewall" so that even if the Normal World is compromised by malware, the assets within the Secure World remain protected.

To see how this applies in practice, let's watch a brief video that gives concrete examples of what kind of tasks are allocated to each world.

2. The Foundation: Hardware-Enforced Isolation

The isolation between the Secure and Normal worlds is not just a software convention; it's enforced by the processor and SoC hardware at a fundamental level. This enforcement happens in three key areas: processor state, memory, and peripherals.

Processor State

The processor core itself is always aware of its current security state.

• In older ARM architectures (like ARMv7), this is managed by the NS (Non-Secure) bit in the Secure Configuration Register (SCR).
• In the ARMv8-A architecture, security state is integrated with the Exception Level model. EL3 is always Secure, and it controls whether EL2, EL1, and EL0 are in Secure or Non-secure state via the SCR_EL3.NS bit.

When the processor is in the Non-secure state, its ability to access certain system resources and execute privileged instructions is restricted by the hardware.

Memory and Peripheral Isolation

This is the most critical aspect of the hardware enforcement. The system bus is extended with an additional signal, often conceptualized as a "33rd bit" on a 32-bit address bus, which indicates whether a memory access is Secure or Non-secure.

• Two Physical Address Spaces: TrustZone effectively creates two parallel physical address spaces: Secure and Non-secure. This means that physical address 0x8000_0000 in the Secure space is a completely different location from physical address 0x8000_0000 in the Non-secure space.
• Access Control Rules:
  • When the processor is in Non-secure state, it can only generate Non-secure memory accesses. Any attempt to access an address marked as Secure will be blocked by the hardware and will trigger a fault exception.
  • When the processor is in Secure state, it can access both Secure and Non-secure memory. The Memory Management Unit (MMU) uses a special NS bit in its page table entries to determine which physical address space a given virtual address should map to.

This principle extends beyond the processor to the entire SoC. Peripherals on the bus (like DMA controllers, crypto accelerators, or specific GPIO banks) can be configured to be Secure or Non-secure, meaning they will only respond to transactions with the correct security attribute.

The following video provides a detailed look at how the MMU and even the CPU caches are made "TrustZone-aware" to enforce this isolation.

3. Crossing the Boundary: The Secure Monitor

Since the two worlds are strictly isolated, how does the Normal World ask the Secure World to perform a service, like encrypting data? Direct calls are forbidden.

The only way to transition between worlds is by triggering an exception that is routed to the highest privilege level in the Secure state:

• In ARMv8-A, this is Exception Level 3 (EL3).
• In older ARM architectures, this is a special mode called Monitor Mode.

The software running at this level is called the Secure Monitor. It acts as the sole gatekeeper between the two worlds.

A transition is typically initiated in one of two ways:

1. Software Request: The Normal World executes a SMC (Secure Monitor Call) instruction. This is a deliberate trap into the Secure Monitor to request a specific service.
2. Hardware Interrupt: An interrupt (IRQ or FIQ) can be configured to always be taken by the Secure Monitor first. The Monitor can then process the interrupt or decide to forward it to the Normal World for handling.

When a transition occurs, the Secure Monitor is responsible for:

• Saving the full context (registers) of the current world.
• Switching the processor's security state.
• Restoring the context of the world being switched to.

This context switching is crucial for maintaining the isolation.

4. Cortex-A vs. Cortex-M: Different Architectures, Same Goal

While you are likely familiar with Cortex-A series processors from ADAS platforms, you may also encounter Cortex-M microcontrollers which also feature TrustZone. The implementation, called TrustZone-M, is adapted for the simpler architecture of MCUs.

The key differences are:

• Memory Partitioning: Cortex-M processors lack an MMU. Instead, they use a Security Attribution Unit (SAU) (and optionally a vendor-specific IDAU) to define regions of the flat memory map as Secure, Non-secure, or Non-secure Callable (NSC).
• World Transitions: Instead of a full-blown Secure Monitor, transitions from the Non-secure to the Secure world are made through special functions located in the NSC memory region. These functions use a SG (Secure Gateway) instruction, which acts as a controlled entry point into the Secure world. This is a much more lightweight mechanism suitable for MCUs.

Understanding both implementations is valuable, as you may encounter SoCs that use Cortex-A for the main application processing and an embedded Cortex-M as a dedicated secure enclave or safety island.

5. Interview Corner

Q1: What is ARM TrustZone and what fundamental problem does it solve in an embedded system?
A: ARM TrustZone is a system-wide security architecture that partitions the processor and SoC into two isolated environments: a Secure World and a Normal World. It solves the problem of protecting critical assets (like keys, cryptographic operations, and secure firmware) from a large and potentially vulnerable software stack (like a rich OS and third-party apps). By using hardware enforcement, it ensures that even if the Normal World is compromised, the Secure World remains intact.

Q2: How does TrustZone enforce isolation between the Secure and Non-Secure worlds? Describe the key hardware mechanisms.
A: The isolation is hardware-enforced. First, the processor has a distinct Security State (Secure or Non-secure). Second, the memory system is partitioned into two physical address spaces. An extra bus signal indicates the security of each transaction. The hardware enforces a strict rule: code running in the Non-secure state can only make Non-secure accesses. An attempt to access a Secure memory location or peripheral results in a hardware fault. Code in the Secure state can access both, with the target address space determined by the MMU/SAU configuration. This extends to caches, MMUs, and peripherals across the SoC, which are all "TrustZone-aware".

Q3: A developer wants the infotainment system (running in the Normal World) to get a unique device ID that is stored in a protected fuse box (a Secure peripheral). How can this be achieved using TrustZone?
A: Direct access is not possible or allowed. The correct architectural approach is for the infotainment application to make a system call to its OS, which then executes an SMC (Secure Monitor Call) instruction. This traps execution into the Secure Monitor (at EL3). The SMC call would have parameters indicating a request for the device ID. The Secure Monitor would then switch context to a trusted application in the Secure World. This trusted application would read the device ID from the Secure fuse box peripheral and then return the value back to the Secure Monitor. The Monitor would then switch context back to the Normal World, delivering the device ID as the return value from the original SMC call. This ensures the Normal World never directly accesses the secure hardware.

Conclusion

In this lesson, we explored the ARM TrustZone architecture, a cornerstone of modern embedded system security. You learned how it creates a hardware-enforced separation between a trusted, secure environment and a less-trusted, normal environment.

Key Takeaways:

• TrustZone divides a system into an isolated Secure World (for trusted code/data) and a Normal World (for rich OS/apps).
• Isolation is enforced by hardware: the processor's security state, separate physical address spaces, and access control logic in the memory system and peripherals that check the NS (Non-secure) attribute of every transaction.
• Transitions between worlds are arbitrated exclusively by a highly privileged Secure Monitor (running in Monitor Mode or EL3).
• The Normal World deliberately requests services from the Secure World using the SMC instruction.
• The architecture is adapted for different processor profiles, with TrustZone-M for Cortex-M MCUs using an SAU and Secure Gateways instead of an MMU and a full monitor.

Next Lesson Preview:
Now that we understand the architecture of TrustZone, our next step is to see how these worlds communicate in practice. In the next lesson, we will focus on implementing a Secure Monitor Call (SMC) to transition from the Non-Secure world to the Secure world to execute a protected function.