ARM Assembly Part 13: TrustZone & ARM Security Extensions

Introduction & Security Model

TrustZone adds a single hardware bit — the NS (Non-Secure) bit — to every bus transaction on the AMBA AXI bus. Peripherals and DRAM controllers use this bit to enforce access control: Secure-world transactions (NS=0) can reach any address; Non-Secure transactions (NS=1) are blocked from Secure-only regions by the TZASC (TrustZone Address Space Controller) and TZPC (TrustZone Protection Controller). The CPU's current world is determined by SCR_EL3.NS at EL3, and by the implied state when running below EL3.

Secure vs Non-Secure Worlds

SCR_EL3 — Secure Configuration

// SCR_EL3 key bits:
// [0]  NS  — 0=Secure, 1=Non-Secure (current world when in EL1/EL0)
// [1]  IRQ — 1=IRQs taken to EL3 (else to EL1)
// [2]  FIQ — 1=FIQs taken to EL3
// [3]  EA  — 1=SErrors taken to EL3
// [4]  SMD — 1=Disable SMC instruction at EL1 and above
// [10] RW  — 1=EL1 is AArch64 (0=AArch32)
// [11] SIF — 1=Secure instruction fetch from Non-Secure memory prohibited

// Enter Non-Secure world from EL3 (Linux boot scenario):
MRS  x0, SCR_EL3
ORR  x0, x0, #(1 << 0)   // NS=1: EL1 will be Non-Secure
ORR  x0, x0, #(1 << 10)  // RW=1: EL1 is AArch64
ORR  x0, x0, #(1 << 2)   // FIQ=1: route FIQ to EL3 (for secure interrupts)
BIC  x0, x0, #(1 << 4)   // SMD=0: SMC allowed from NS EL1
MSR  SCR_EL3, x0
ISB

NS Bit & Memory Tagging

Every read/write from the CPU carries the current world's NS bit through the cache and memory bus. The TZASC (typically AXI TrustZone Address Space Controller v1/v2 or GPC for newer SoCs) is configured at boot by Secure firmware to mark regions as Secure-only. Non-Secure masters attempting to access those physical pages receive a bus abort. This is enforced in hardware, independent of the MMU, making TrustZone the foundation for features like Android Strongbox keys, iOS Secure Enclave equivalents, and DRM content protection.

Banked Registers per World

Each world has its own complete set of EL0/EL1 system registers: TTBR0_EL1, TTBR1_EL1, TCR_EL1, SCTLR_EL1, SPSR_EL1, ELR_EL1, SP_EL0, SP_EL1, and the entire NEON/FP register file. When EL3 switches worlds by writing SCR_EL3.NS and executing ERET, the processor transparently switches to the Secure copies of these registers, giving the trusted OS its own fully independent virtual memory space and register state.

SMC — Secure Monitor Call

SMCCC Calling Convention

The ARM SMC Calling Convention (SMCCC v1.2) standardises how software invokes EL3 services. x0 contains the function identifier (32-bit encoding: [31]=call type, [30:24]=OEN, [16]=SMC32/64, [15:0]=function). x1–x7 carry arguments. EL3 services return results in x0–x3 (SMCCC ≥ 1.2: also x4–x7). This convention is used by PSCI, vendor-specific services, and hypervisor SMC calls.

// SMCCC example: PSCI CPU_ON to boot a secondary CPU
// Function ID: 0xC4000003 = PSCI64 CPU_ON
// x0 = Function ID, x1 = target MPIDR, x2 = entry_point_address, x3 = context_id
MOV  x0, #0xC4000003       // PSCI CPU_ON (SMC64)
MRS  x1, MPIDR_EL1         // Read own MPIDR (modify to target CPU)
ORR  x1, x1, #(1 << 8)    // Point to CPU1 (Aff1=1)
ADR  x2, secondary_entry   // Secondary core entry point
MOV  x3, #0                // Context ID
SMC  #0                    // Invoke EL3 secure monitor

// On return: x0 = PSCI_SUCCESS (0) or error code
CMP  x0, #0
B.NE psci_error

PSCI — Power State Coordination Interface

PSCI is the most common SMC-based service. It provides CPU_SUSPEND, CPU_OFF, CPU_ON, SYSTEM_OFF, SYSTEM_RESET, and MIGRATE functions, allowing the OS to manage CPU power states without requiring platform-specific code. Linux's CPU hotplug, idle framework (cpuidle), and kexec all use PSCI SMC calls. TF-A's BL31 implements the PSCI runtime service handlers at EL3.

Trusted Firmware-A (TF-A)

BL1→BL2→BL31→BL33 Boot Chain

BL31 Runtime Services

// BL31 SMC dispatch (simplified TF-A pattern)
// When SMC is trapped to EL3, BL31 runtime:
// 1. Save Non-Secure context (NS GPRs, SP, ELR, SPSR)
// 2. Decode x0 function identifier → route to service handler
// 3. If dispatching to S-EL1 (OP-TEE):
//    - Set SCR_EL3.NS=0
//    - Restore Secure EL1 context
//    - ERET to S-EL1 (OP-TEE) handler
// 4. When S-EL1 finishes: SMC back to EL3
//    - Save Secure context
//    - Set SCR_EL3.NS=1
//    - Restore NS context
//    - ERET back to NS caller

// Pseudo-code equivalent in assembly:
el3_smc_handler:
    SAVE_NS_CONTEXT x18           // Macro: save x0-x29, SP, ELR, SPSR
    BL    smc_dispatch_c          // C: decode x0, return target world
    CBZ   x0, return_to_ns        // 0 = return to NS, 1 = go to secure
    RESTORE_SECURE_CONTEXT x18
    MSR   SCR_EL3, x19            // SCR_EL3 with NS=0
    ERET                          // Jump to Secure EL1

Hardware Root of Trust

A Hardware Root of Trust (HRoT) anchors the entire TrustZone security model in tamper-resistant silicon. Without it, even a perfectly configured TF-A boot chain could be subverted by flashing modified firmware. The HRoT ensures that the very first instruction executed after power-on is authentic and untampered.

OTP Fuses for Boot Key Storage: The SoC contains One-Time Programmable (OTP) fuses — eFuses that are physically burned during manufacturing. These store the SHA-256 hash of the root-of-trust public key (ROTPK). BL1 in ROM reads this hash and verifies BL2's certificate chain against it. Because eFuses are write-once, an attacker cannot replace the key even with physical access to the chip.

Anti-Rollback Counters: OTP fuses also store monotonic anti-rollback counters (NV counters). Each signed firmware image includes a minimum counter value; BL1/BL2 refuse to load any image whose counter is below the fused value. When a security-critical update ships, the new firmware burns the next fuse bit, permanently preventing rollback to vulnerable versions.

Hardware Entropy Sources (TRNG): Secure key generation requires unpredictable randomness. ARM CryptoCell and similar IP blocks include a True Random Number Generator (TRNG) based on ring-oscillator jitter or thermal noise. The TRNG is mapped to the Secure address space only — Non-Secure software must request random bytes via an SMC call to a Trusted Application, ensuring the entropy source cannot be manipulated or observed by the Normal world.

Certificate Chain Verification in Secure Boot: TF-A implements a Certificate of Trust (CoT) model: BL1 verifies BL2's content certificate using the ROTPK hash from OTP. BL2 then verifies BL31, BL32, and BL33 certificates in a chain. Each certificate binds the image hash to the signing key, and each key is itself signed by its parent. A single broken link in this chain halts the boot process entirely — the SoC enters a secure fault state rather than booting compromised firmware.

World Switch Assembly

Non-Secure → Secure

The Non-Secure OS issues an SMC to request a Trusted Application service (e.g., decrypting a key with OP-TEE). EL3 (BL31) receives the SMC, saves the entire Non-Secure CPU context (x0–x30, SP_EL0, SP_EL1, ELR_EL1, SPSR_EL1, all FP/NEON registers) to a context save area, then restores the Secure EL1 context and sets SCR_EL3.NS=0 before ERETing to the trusted OS.

Secure → Non-Secure Return

// OP-TEE: return result to Non-Secure caller via SMC
// x0 = OPTEE_SMC_RETURN_OK (0)
// x1-x3 = return values
MOV  x0, #0                // OPTEE_SMC_RETURN_OK
SMC  #0                    // Trap back to EL3 (BL31)

// BL31 on return:
// 1. Decode x0 as OPTEE return
// 2. Save Secure EL1 context
// 3. Set SCR_EL3.NS = 1
// 4. Restore Non-Secure context (x0 holds PSCI/TEE result)
// 5. ERET to NS EL1 (after the original SMC instruction)

S-EL1 Trusted OS (OP-TEE)

OP-TEE (Open Portable Trusted Execution Environment) runs at S-EL1 under TF-A. It has its own MMU (TTBR0 in Secure state), exception vector table, and scheduler for Trusted Applications (TAs). TAs are loaded as ELF binaries into Secure memory and execute at S-EL0. Communication with the Normal world uses shared memory buffers whose physical addresses are passed via SMCCC parameters — the OP-TEE driver in the Linux kernel handles encoding these calls and mapping the shared buffers.

TZASC & Memory Partitioning

The TrustZone Address Space Controller (ARM TZASC-400/TZASC-380 / GPC in DynamIQ) divides physical memory into Secure, Non-Secure, and shared regions. BL2 configures the TZASC before loading BL32/BL33 — typically reserving the top 16–32 MB of DRAM as Secure for OP-TEE and its TAs. TZPC (TrustZone Protection Controller) gates peripheral access for devices like the Secure keyboard, biometric sensor, or cryptographic accelerator, ensuring only Secure-world transactions can reach them.

Hands-On Exercises

ARM Security Audit Tool

Use this tool to document your TrustZone security architecture, threat model, and mitigations. Export as Word, Excel, or PDF for security review documentation.

Conclusion & Next Steps

We dissected ARM TrustZone: the NS bit propagation through AMBA buses, SCR_EL3 configuration, the banked Secure/Non-Secure register files, the SMCCC standard (including PSCI CPU_ON), TF-A's BL1→BL2→BL31→BL33 boot chain, BL31 SMC dispatch, world-switch assembly for NS→Secure and back, OP-TEE's S-EL1 architecture, and TZASC/TZPC memory and peripheral partitioning.