Papers
Topics
Authors
Recent
2000 character limit reached

ARM TrustZone: Secure Execution Environment

Updated 26 December 2025
  • ARM TrustZone is a hardware-based trusted execution environment (TEE) for ARM processors that partitions system resources into Secure and Non-Secure worlds to protect sensitive operations.
  • It employs mechanisms like Secure Monitor Calls and controllers such as TZASC and TZPC to enforce strict memory and peripheral isolation between domains.
  • The architecture supports secure boot, cryptographic verification, and trusted applications, setting the stage for advancements like Arm Confidential Computing.

ARM TrustZone is a hardware-based trusted execution environment (TEE) architecture for ARM processors, widely deployed in consumer, IoT, and industrial systems to provide memory and peripheral isolation for trusted code and data. TrustZone divides system resources into two worlds—Secure and Non-Secure—enforcing a hardware boundary such that the Secure World maintains confidentiality and integrity of sensitive operations even in the presence of a compromised non-secure OS.

1. Architecture and Isolation Mechanisms

ARM TrustZone partitions a single ARM core (and typically the full SoC interconnect) into Secure and Non-Secure worlds. Each world operates under distinct privilege contexts, translation regimes, and memory regions. Every bus transaction, instruction fetch, DMA transfer, or peripheral access is tagged with an NS-bit, which determines access rights:

  • Secure World (SW): Runs a minimal trusted OS (e.g., OP-TEE), Trusted Applications (TAs), and holds sensitive assets such as cryptographic keys.
  • Non-Secure World (NW/REE): Runs conventional OS (Linux, Android), device drivers, and untrusted user applications.

Transitions between worlds are performed via the Secure Monitor Call (SMC) instruction. Upon SMC execution, the Secure Monitor (firmware at EL3) saves processor state, flips the NS-bit, and switches context. World-switches are atomic and managed entirely by hardware, preventing direct cross-world register access.

Memory isolation is achieved with the TrustZone Address Space Controller (TZASC) and TrustZone Peripheral Controller (TZPC), which partition RAM and MMIO regions such that:

  • Secure World can access all regions, including Non-Secure.
  • Non-Secure World is barred from Secure-only regions.

On Cortex-M variants, the Secure Attribute Unit (SAU) and Implementation Defined Attribution Unit (IDAU) configure secure boundaries in SRAM and flash, with explicit control over non-secure callable regions for NS→S transitions (Sarker et al., 2023).

2. Trusted Execution, Boot, and Chain of Trust

At boot, ARM Trusted Firmware (ATF, typically at EL3) implements a measured boot chain:

  • BootROM validates BL1, which verifies and loads BL2.
  • BL2 verifies the TEE OS image (e.g., OP-TEE), authenticating with signatures rooted in on-chip eFUSE or device certificates.
  • Once Secure World is established and locked, control is handed to the non-secure bootloader (Linux, Android). Any attempt by the REE to tamper with secure memory or peripherals is hardware-blocked (Gupta, 2024).

Trustlets (user-mode TAs) and TEE OS code are cryptographically verified before loading. Unfortunately, widespread key reuse and lack of monotonic version checks frequently allows rollback attacks, where an adversary reinstalls old, vulnerable trustlets or TEE OS images. As documented, major devices across vendors (Google, Qualcomm, Samsung, Huawei) were shown to lack rollback prevention and shared verification keys, enabling exploit persistence past patching unless hardware version counters or key rotation are enforced (Chen et al., 2017).

3. Secure World Execution Models and Application Integration

Trusted Applications (TAs) reside in Secure World and are typically invoked via well-defined APIs (GlobalPlatform TEEC APIs) with explicit shared buffers for communication between worlds (Gupta, 2024). Secure services include cryptographic operations, integrity checks, secure file access, attestation, and isolated execution for security-sensitive workloads.

Application models include:

  • On-device confidential LLM inference: Model parameters and execution are confined to Secure World, with flow control over NPUs and secure memory allocation (e.g., pipelined operator restoration, co-driver architecture for NPUs) to balance latency and TCB size (Wang et al., 17 Nov 2025).
  • Industrial control integration: TA-based key management, runtime code integrity, and secure storage are used to protect gateway and PLC logic even with full REE compromise (Li et al., 2024, Gupta, 2024).
  • Deceptive file activity cloaking: Secure World orchestrates sybil-augmented filesystem activity to obfuscate access patterns, achieving probabilistic guarantees much cheaper than cryptographic ORAM (Guo et al., 2022).

Secure World code is subject to stringent memory and privilege isolation; on ARM Cortex-M, calls into the Secure World must transit through Secure Gateway veneers and be declared with compiler attributes enforcing register and pointer sanitization. Compromises in buffer handling or parameter validation can lead to total loss of TEE isolation, as seen in MOFlow (overflow) and Achilles' Heel (unchecked pointer) attacks, which enable exfiltration of other TAs' memory (Sarker et al., 2023).

4. Hardware-Backed Peripherals and Secure IO

TrustZone enables secure access and isolation of peripherals via TZPC configuration and strong separation of MMIO address spaces:

  • Peripheral on/off control: SeCloak configures CSU/TZASC registers to mask devices at hardware level, reliably disabling radios, cameras, and microphones, and emulates instruction faults for policy granularity without requiring OS changes (Lentz et al., 2020).
  • Device driver integration: Driverlets replay parameterized IO interaction templates, minimizing the TCB while supporting complex devices with symbolic execution and taint analysis to extract state-changing events. The approach is correct for data-independent interfaces and reduces driver attack surface by eliminating kernel-level driver code from SW (Guo et al., 2021).
  • DMA and NPU isolation: Memory partitioning via TZASC and secure bootstrapping of NPU MMIO ensures inference jobs and co-driver routines in SW cannot be hijacked through REE DMA (Wang et al., 17 Nov 2025).

5. Security Analysis, Measurement, and Attestation

TrustZone's hardware isolation creates a robust foundation for code and data confidentiality. Runtime threats remain significant when secure world is exposed to persistent or dynamic modifications:

  • Measurement and attestation: PDRIMA introduces a Secure Monitor Agent to perform policy-driven integrity measurement and appraisal over the TEE kernel, static and dynamic TAs, and system calls. Evidence is hash-chained and logged inside the SW and provided to remote verifiers via a dedicated attestation protocol (e.g., signatures over vPCRs and SMLs bound to nonces), closing the boot-to-runtime trust gap (Mao et al., 6 Dec 2025).
  • End-to-end IO protection: Publish-subscribe brokers (MQT-TZ) use hardware-backed TEEs to isolate keys and re-encrypt all message payloads, preventing in-broker data leakage even at elevated kernel privilege (Segarra et al., 2020).
  • File access pattern protection: Enigma overlays multiple filesystem images and injects sybil calls to achieve Pdetection≤1KP_{\text{detection}}\leq \frac{1}{K} secrecy with only order-of-magnitude lower overhead than cryptographic address obfuscators (Guo et al., 2022).

TrustZone remains vulnerable to misconfiguration, supply chain attacks, and run-time privilege escalation—especially in the absence of enforcement of least-privilege for TAs and lack of runtime integrity coverage across all SW assets (Mao et al., 6 Dec 2025). The over-privileged nature of Secure World and direct access to Normal World memory is a known limitation in TEEs for mutual isolation, as highlighted by Android and confidential compute research (Kuhne et al., 2024).

6. Performance, Overheads, and Best Practices

Micro- and macro-benchmarks establish the quantitative costs of TrustZone isolation mechanisms:

Operation Typical Overhead in SW Notes
World-switch (SMC) 110–160 μs Dominant for fine-grained RPCs
Secure storage (1 MB write) 210 ms Linear with size; costly for bulk
TA-crypto (AES) ~10–80× REE OpenSSL On-chip crypto acceleration advised
File deception (Enigma) 8–28% I/O overhead Scales gracefully with K images
Driverlet replay 1.4–2.7× vs. native TCB reduction ≫ runtime cost
NPU co-driver (TZ-LLM) ≤ 3% extra TTFT Small TCB increment (~1 KLoC)

Best practices for development include:

  • Strict input validation at all NSC boundaries and use of safe buffer allocations.
  • Compiler-enforced use of __attribute__((cmse_nonsecure_entry)) and explicit memory range checks.
  • Minimal TCB in Secure World; offload complex logic (drivers, routing, network stack) to REE whenever feasible.
  • Regular session batching or caching to amortize world-switch costs in high-throughput workloads (Amacher et al., 2019, Wang et al., 17 Nov 2025).
  • Signed TAs and firmware with monotonic version counters for rollback prevention (Chen et al., 2017).
  • Static analysis and Secure World–aware linters to enforce boundary and pointer safety (Sarker et al., 2023).

7. Extensions and Future Directions

Recent research pushes TrustZone beyond its two-world abstraction toward finer-grained, mutually isolated sandboxes, and confidential compute capabilities:

  • Arm Confidential Computing Architecture (CCA): Augments TrustZone with Realm World and memory granule protection tables for mutually isolated execution. Sandboxed services (Aster) use programmable resource tags to deny cross-access even from Secure World (Kuhne et al., 2024).
  • Virtualized CCA with TrustZone (virtCCA): Implements the full CCA RMI stack in TrustZone Secure World using either S-EL2 (hardware VT) or EL3-only software trapping. cVM life-cycle and memory isolation matches future Realm guarantees while maintaining compatibility with KVM and CCA APIs at modest overhead (Xu et al., 2023).
  • Dynamic resource management: LEAP enables per-core sandboxes with exclusive device MMIO mapping and automatic app slicing, providing developer-friendly TEEs with near-native performance for ML workloads (Sun et al., 2021).

TrustZone-equipped platforms will increasingly integrate runtime measurement engines, confidential compute abstraction, and scalable IO isolation to meet demands in mobile, edge, and industrial settings. Persistent challenges include enforcing least privilege, eliminating rollback vectors, achieving full runtime attestation, and eradicating supply chain key reuse across device generations.

Whiteboard

Topic to Video (Beta)

Follow Topic

Get notified by email when new papers are published related to ARM TrustZone.

Don't miss out on important new AI/ML research

See which papers are being discussed right now on X, Reddit, and more:

“Emergent Mind helps me see which AI papers have caught fire online.”

Philip

Philip

Creator, AI Explained on YouTube