Secure Enclaves on Commodity Arm Processors: TrustZone, Its Benefits, Its Limitations, and the Evolution Toward Arm CCA

Abstract

Modern processors rely on privilege levels to isolate software (also known as rings on x86), but this hierarchy forces user-level workloads to trust a substantial amount of over-privileged and potentially vulnerable code. This article examines Arm TrustZone as a hardware-enforced approach to secure execution on commodity processors, isolated from most of the large body of privileged system software that user-level workloads are otherwise forced to trust. TrustZone partitions system resources into secure and normal worlds, enabling a minimal Trusted Operating System and trusted applications to operate alongside a feature-rich normal world. The article describes the TrustZone access-control model, secure monitor communication, and the hardware components used to protect execution, memory, and peripherals. It also discusses vendor-specific implementation variability across Cortex-A platforms and presents a representative system model for the analysis. Finally, the article examines TrustZone’s architectural limitations and known vulnerabilities before introducing Arm Confidential Compute Architecture as a more recent evolution towards confidential computing, addressing key limitations of TrustZone.

Introduction

Processors commonly employ multiple privilege levels, ranging from least-privileged application software to highly privileged system software. Although these levels enforce a hierarchical (bottom-up, vertical) isolation, this layered isolation can be limiting in some situations.

An operating-system kernel such as Linux [2] presents a significant attack surface. It contains a substantial amount of code written in unsafe low-level languages such as C and assembly, while running with extensive privileges over the system. Vulnerabilities in this privileged code can have serious consequences, requiring user processes to trust a large body of potentially vulnerable kernel code.

For example, if a malicious user managed to exploit a vulnerability in the kernel, it may be able to read sensitive information from the kernel itself or memory belonging to other processes [30], potentially exposing privacy-sensitive activities or security-sensitive data such as banking credentials.

The use of cryptography to "hide" data at rest limits the scope of attacks, but privileged software traditionally has access to all the system's memory and could therefore leak encryption keys [29] or clear-text data in use. Another approach to isolating sensitive resources is to use a dedicated security chip that is physically isolated from the main processor, providing strong security guarantees [28]. However, these chips typically operate at much lower frequencies than the application processor and the additional hardware might be too expensive (either in space or in financial cost). To run security-sensitive workloads without sacrificing performance or adding an extra chip on the platform, secure enclaves offer an alternative by providing isolation directly on the application processor.

To support this approach, Arm introduced the TrustZone security extensions [4] for its application processors. Where traditional processors only enforce a vertical isolation (i.e., between different privilege levels), TrustZone also provides horizontal isolation, between components running at the same exception level (EL) [3]. On Arm AArch64 processors implementing these extensions, this isolation is enforced in hardware, splitting the system into two isolated execution environments, called worlds.

While TrustZone has been the primary trusted computing technology on Arm platforms for many years [31], its design also introduces several architectural limitations and security vulnerabilities. More recently, Arm introduced the Confidential Compute Architecture (CCA) as part of the so-called Realm Management Extension (RME), addressing many of these shortcomings.

Important note

The Armv8 architecture specification for the Cortex-A family of processors leaves open several aspects of the specification. A vendor may choose, e.g., whether to implement EL3, whether to provide the non-secure and/or secure EL2 hypervisor level, how many secure regions an address space controller supports, or which TrustZone hardware components are included on the SoC.

For instance, the Raspberry Pi 4 implements the secure world with kernel and user modes, but does not enforce world-based access control on memory, as it lacks a TrustZone Address Space Controller [1].

In this article, we consider a representative TrustZone-enabled system that implements EL0 and EL1 in both the secure and normal worlds, together with (secure) EL3. The hypervisor layer (S/NS-EL2) is omitted for simplicity, although it may be mentioned where relevant. We also assume that the platform provides the TrustZone hardware components necessary for the implementation of a trusted execution environment, as shown in Figure 3 and described in hardware enforcement. This model describes a generic implementation and does not apply uniformly to all Cortex-A platforms.

Trusted Computing with Arm TrustZone

Arm AArch64 processors implement several privilege levels known as Exception Levels (ELs) [3]. Similar to privilege rings on x86 processors, these levels provide hierarchical isolation by restricting access according to privilege. Higher privilege levels may access lower ones, while lower privilege levels cannot access software executing with higher privileges.

Although effective for basic privilege separation, this model only provides vertical isolation, between different exception levels. Any separation between components running at the same EL, such as user-space processes under a kernel or virtual machines under a hypervisor, instead relies on mechanisms configured and controlled by the level above them. It is therefore only as trustworthy as that software, which, again, exposes a large attack surface.

TrustZone introduces a second isolation mechanism based on two hardware-enforced execution environments known as the Secure World and the Normal World [4]. Rather than relying exclusively on privilege levels, platform resources such as execution context, memory, and peripherals are partitioned into secure and non-secure regions.

As depicted in Figure 1, the secure world hosts a minimal Trusted Operating System together with Trusted Applications responsible for security-sensitive operations. Device drivers, networking stacks and other feature-rich services typically remain in the normal world, also referred to as the Rich Execution Environment (REE) or Rich OS in the literature [10].

Entry in EL3 is done purposely through the SMC (secure monitor call) privileged instruction. In the kernel, this conduit method is typically replaced by the also privileged hypervisor call HVC when EL2 is implemented and hosts a hypervisor. The SMC instruction triggers a synchronous abort and traps into the exception vector at EL3 -- specifically, at VBAR_EL3 + 0x400 or VBAR_EL3 + 0x600 when all lower ELs run in the AArch32 execution state [3].

Although this article focuses more on the hardware enabling trusted computing, we will take a short detour and briefly explore how communication between the secure and normal worlds takes place.

Applications executing in the normal world that invoke trusted applications are commonly referred to as client applications (CA). As shown in Figure 2, when a client application wishes to call a routine in a TA, it must first call into the normal world TEE driver, since the SMC instruction can only be called from a privileged context. The TEE driver can be simplified to a character device module in the Linux kernel, which the untrusted user application can write to by, e.g., an ioctl call to the device file. The TEE driver can then issue the secure monitor call on the CA's behalf to transmit its request. The expected format for such calls is well-defined and must comply with the secure monitor call calling convention (SMCCC) [5]. The SMC will be handled by a so-called runtime service in EL3, here the TEE dispatcher. The TEE dispatcher will in turn forward the payload to the TEE kernel which can then schedule and call into the requested TA.

We will discuss how the current security state can be changed by the secure monitor in the section dedicated to hardware enforcement.

Threat Model

TrustZone provides hardware primitives for protecting the confidentiality and integrity of resources assigned to the secure world against software executing in the normal world. Although guarantees of availability could also be achieved [15, 16, 17], they are typically not implemented, as trusted kernels are mainly designed as passive, companion kernels, scheduled by the normal world via a defined set of APIs [18]. For the purpose of keeping a small TCB, the secure world does not typically implement device drivers or a file system. As a result, when such functionalities are needed, the secure software requests the normal world to perform the action on its behalf. A malicious non-secure kernel could naturally cause a denial of service by refusing to answer the request and not returning from the call. Furthermore, TrustZone does not provide protection against physical attacks and is, in fact, vulnerable to side-channel attacks [14, 19].

Accordingly, the threat model assumes that the normal world may be malicious and may attempt to read, modify, or interfere with secure resources. TrustZone is intended to preserve their confidentiality and integrity, but availability is most of the time not part of the equation.

We also note that the security of secure-world software depends directly on the correct and bug-free implementation of the secure monitor (trusted firmware) as well as the platform hardware, which collectively form the trusted computing base (TCB) of the trusted execution environment (Secure EL2-0) [19].

Hardware Enforcement

All hardware elements described in this section are illustrated on Figure 3.

TrustZone isolation is enforced by dedicated hardware rather than software alone. The current security state is determined by the Non-Secure (NS) bit in the Secure Configuration Register (SCR) [4], which can only be updated by the most privileged exception level implemented, in our case, EL3.

On-chip memories are statically partitioned using the TrustZone Memory Adapter (TZMA), while off-chip DRAM protection is provided by the TrustZone Address Space Controller (TZASC) [7, 8], which can be statically and dynamically configured, depending on the hardware implementation. Every memory transaction is checked against the configured security policy before reaching memory [6].

Interrupts are isolated by the TrustZone-aware Generic Interrupt Controller (GIC) [9], which distinguishes secure and non-secure interrupts, while peripherals are protected using the TrustZone Protection Controller (TZPC) [27], allowing hardware devices to be assigned to either execution world. Secure interrupts can only be delivered to the secure world and the normal world cannot modify their configuration.

Together, these components ensure that accesses to secure execution context, memory, and peripherals comply with the configured security policy.

Since most of this hardware is not standardized within the Arm TrustZone specification, OEMs can decide whether or not to implement them, and frequently use proprietary designs. IP designs sometimes use the term firewall [26] to refer to their access control architecture.

Summary of Benefits

TrustZone complements the processor's privilege hierarchy with a hardware-enforced separation between the normal world and a newly introduced secure world. The partitioning of platform resources allows the execution of sensitive workloads in isolation from the normal world, providing guarantees of integrity and confidentiality with a small trusted computing base.

Furthermore, by running on the main processor, those security-sensitive applications benefit from the same performant application cores as untrusted software.

So, as Dr. Pangloss would say, "All is for the best in the best of all possible worlds" (Candide, Voltaire).

Unfortunately, no.

Limitations

TrustZone is an aging technology: it was first implemented in the ARM1176JZ(F)-S processor, released in 2004 [6, 11]. It is known to be vulnerable to privilege-escalation attacks, fault-injection attacks, and several other classes of attacks [13, 14].

TrustZone also does not provide strong isolation between the secure monitor and the rest of the secure world. This boundary is therefore a potential attack surface: a corrupted trusted kernel could leverage this lack of isolation, gain access to EL3 and undermine the security of the entire platform [12].

Its memory-partitioning model lacks flexibility. Typically, only a limited number of secure carve-outs are supported, with coarse granularity. For example, the TZC-400 [8] address space controller supports eight such partitions, while the 32 kB granularity of isolated partitions limits the flexibility of the protection scheme [25].

Illegal accesses to main memory generate asynchronous aborts. As a result, reconstructing the faulty instruction can be significantly more difficult than when handling a synchronous abort, preventing transparent mechanisms such as trap-and-emulate, or making it substantially harder for the kernel programmer to implement.

Depending on the vendor's implementation, TrustZone may or may not support memory partitioning on a per-core basis (e.g., TZC-400 does, while TZC-380 does not). This depends on whether the address space controller can associate distinct memory partitioning configurations with the identifiers of different manager (formerly master) devices. Without this support, software executing on different cores cannot be given independent memory protection policies (check Sanctuary and Shelter in Further Reading for examples of why this can be an interesting feature) .

Finally, most TrustZone hardware components are neither standardized nor mandatory. Components such as the TZASC and TZPC may therefore be absent or differ in implementation between platforms, limiting the portability of a design across Arm systems.

Toward Arm Confidential Compute Architecture

From Armv9.2 onward, the Arm ISA optionally supports the Realm Management Extensions (RME) for Arm Confidential Compute Architecture (CCA) [20]. RME enhances the existing security states by introducing two additional worlds: the Realm World, which hosts confidential virtual machines (confidential VMs, or CVMs), and the Root World, which runs the firmware and secure monitor. This set of hardware extensions protects the confidentiality and integrity of confidential VMs, also referred to as Realms, by isolating them from both the non-secure and secure worlds. The root world is likewise isolated from all other worlds and is the only world executing at EL3 [21].

CCA organizes memory into four physical address spaces: Non-Secure, Secure, Realm, and Root [21]. As summarized in Table 2, each security state has a defined access policy for these spaces (PAS). The non-secure state can access only the non-secure PAS, while the secure and realm states can access the non-secure PAS together with their respective PAS. The root state can access all four spaces and cannot be accessed by any other security state.

Isolation between these address spaces is enforced by the Granule Protection Check (GPC) [22]. The Memory Management Unit (MMU) [23] performs the GPC on every address translation according to the access-control policy, for which the result can be cached in the TLB. A granule is the smallest block of memory that can be described by this policy, which can be as small as a translation granule. When a translation results in an illegal access, the GPC blocks the access and returns a Granule Protection Fault (GPF) during the translation process.

The assignment of each granule to a PAS is recorded in the Granule Protection Table (GPT), which is stored in the root world, with the base address of its root (called level-0) table held in the GPTBR_EL3 register [21]. GPT entries can describe large fixed regions through level-0 block descriptors or refer to level-1 tables that describe individual granules or ranges of granules. With a block descriptor, the assigned PAS is fixed after initialization. With a table descriptor, the granule protection information can be changed at runtime by the root world; this process is referred to as granule transition.

These mechanisms address several limitations of TrustZone. Instead of relying on a limited number of relatively coarse secure partitions, CCA tracks ownership at the granule level and enforces it for every address translation, generating a synchronous fault in case of illegal access [22]. Moreover, the root world provides an isolated environment for the secure monitor, mitigating previous exploits [12] leveraging its lack of isolation.

Because the Granule Protection Check is performed by the MMU which is a piece of hardware placed inside each core, each core can maintain its own GPT, i.e., its own memory partitioning. Furthermore, RME is defined in the Armv9 architecture specification, so the vendor-specific (vs specification-defined) implementation issue affecting TrustZone's protection components no longer applies to the RME protection model across compliant chips.

Unfortunately, at the time of writing this article, no off-the-shelf board implementing Arm RME is available. However, the research community has proposed solutions such as OpenCCA [24] to enable early exploration and evaluation of Arm CCA on vendor-lock-free, non-CCA hardware.

Conclusion

TrustZone brings hardware-enforced isolation to commodity Arm processors, allowing security-sensitive workloads to execute isolated from feature-rich system software with a reduced trusted computing base. However, its protection model has limited flexibility, depends on vendor-specific hardware support, and leaves a vulnerable boundary between the secure monitor and the rest of the secure world software.

Although not commercially available at the time of writing, Arm CCA is a more recent evolution that provides finer-grained hardware isolation for confidential workloads. It addresses TrustZone's limitations through more flexible memory ownership, generation of synchronous faults in case of illegal access, stronger separation of the secure monitor with the rest of the system, and the ability to readily support independent memory protection across processor cores. All of which are defined in the architecture specification, making portability of system software easier across compliant implementations.