Arm Introduces Its Confidential Compute Architecture

When Arm announced the Armv9 architecture earlier this year, they revealed a new architecture for confidential compute that would be introduced. Today Arm is introducing the new architecture. The Arm Confidential Compute Architecture (CCA) is an isolation technology that builds on Arm’s existing TrustZone technology as its foundation. Within the new CCA architecture, application data is designed to be protected while in use. This includes the prevention of access to private data even from privileged software such as the hypervisor or the operating system. What Arm is introducing today is the first release of the behavior architecture specification for a compliant implementation of the architecture. Today spec introduction is designed to seed the software community and kickstart software enablement. Arm expects around 2-3 years until things reach production readiness and we can expect to see it shipping in silicon.

Note that the Confidential Compute Architecture is part of the new Armv9 architecture. Specifically, it will be an optional feature of the Armv9.2 and will likely eventually become a required extension in a future specification. Software developers will be able to check for CCA support by checking if the Realm Management Extension (RME) feature is present on the CPU (more on this later).

Realms

Previously, a high-trust environment was only accessible to silicon vendors and OEMs through things such as TrustZones. With the new Arm CCA, high-trust environments is being extended to all developers with the hope that it will be used by mainstream workloads. While initially this be implemented by OS-related software, Arm hopes that Realms will find their way into mainstream software such as smartphone apps (more on this later in this article). To that end, the new confidential compute architecture is designed to suit all markets from cloud to mobile, automotive, and to IoT.

At the heart of the Confidential Compute Architecture are “Realms”. Realms are effectively small, individual high-trust environments or enclaves. The Confidential Compute Architecture is designed to prevent private data access across the entire stack right from the silicon. To that end, the CCA provides support for strong protection between mutually distrusting workloads, strong protection against compromised rich operating systems (e.g., Linux, Windows), strong protection against compromised hypervisors, and new protection from applications running within the secure world. In other words, a Realm need not trust anyone. The CCA also supports attestation so that a Realm can verify trust in the device or platform and then present an attestation report to a relying party that can then independently verify trust.

The diagram in the slide below shows a high-level overview of how Arm’s CCA is designed to work. You will notice that there are now two new states beyond the usual ‘Normal’ and ‘Secure’ states. They are called ‘Realm’ and ‘Root’. The new states facilitate the new realm features. We will touch on this later in more detail. Realms are shown in the yellow boxes. When they are created – through the help of the hypervisor – they will migrate to the Realm state. The new realm enclaves cannot be accessed by the hypervisor or any of the TrustZone applications (in green) or even other realms.

Realms can be created and destroyed dynamically on-demand. In striking contrast to TrustZone, resources dedicated to realms such as memory can also be adjusted on-demand (i.e., memory size can be increased or decreased as needed on-demand). The idea here is that by moving large software workloads into their own private realms, applications can have much greater confidence that the data they process and algorithms used cannot be used by other software and services running on the same hardware. A big part of the CCA is protecting realms from the underlying hypervisor. So while it is still responsible for allocating resources and is responsible for things such as scheduling, it is no longer able to access the data within a realm. It’s worth noting that the CCA hardware-based protection includes virtually everything on the diagram shown with the only exception being the very lowest level of firmware (marked Monitor in the diagram).

As far as how many realms can be supported; a system is capable of supporting any number of realms – limited by just the available system resources (i.e., memory, compute power). For example, small IoT devices might have just a handful of realms while a large server SoC might be running 100s of realms. Creating and destroying realms is meant to be light enough operation to be used by any application as desired.

Realm Management Extension (RME)

The architecture specification being released today includes both the hardware requirements and the enabling firmware and software. As we mentioned earlier, the Arm CCA feature is being introduced as an optional feature of the Armv9.2 ISA. Hardware that supports the confidential compute architecture will have the Realm Management Extension (RME) available. At its core, processors that implement the Realm Management Extension have two new hardware capabilities: the creation of realms and dynamic memory assignment.

The first new capability is the new ability to create and destroy hardware-enforced enclaves called realms. As we described them earlier, realms provide data and/or code protection from any other execution environment. This includes the hypervisor, kernel, other realms, and even TrustZone applications.

When looking at a typical Arm processor with TrustZone support, the system is partitioned into two regions: one is a secure world and the other is a non-secure world (or normal world). Memory mapping divides the secure world from the non-secure world. Historically, one of the limitations that can impact the use of TrustZone is that memory has to be allocated to the secure world by the Monitor at boot time. And this is often done with limited granularity. This imposes various artificial constraints on the kind/size of resources that may be allocated to the secure world. With the new Realm Management Extension, pages can now transition from the non-secure world to the secure world and back again. This allows TrustZone to be utilized for much more memory-intensive applications. As a side note, when RME is being used exclusively for the enhancement of TrustZone (i.e., no Realms) with dynamic memory capabilities, this specific feature is now being called “Arm Dynamic TrustZone Technology.”

New RME States: Realm & Root

Under the current architecture (Armv8.4-SecEL2), there are two worlds: Secure and Non-Secure (Normal). Each world is associated with its own security state (secure/non-secure) and a physical address space. The secure world is protected from the normal world at exception level 2 and above. Any attempt to access secure memory address space from the normal world will generate a hardware exception, halting execution. Software running within the secure world is able to access both secure and normal world memory.

Under the new RME, two new security states have been added: Root and Realm. Additionally, two new physical address spaces (also called Root and Realm) have been added. The lowest level of the hardware stack – the Monitor – now gets its own private address space and state called ‘Root’. The new Root address space is protected from all other address spaces even the secure world.

The new Realm Management Extension provides the ability to dynamically transition pages of memory between these physical address spaces. Arm calls those pages Granules. In order for the processor to support the new dynamic transitioning of memory pages between the various address spaces, Arm added a new table called the Granule Protection Table or GPT. The GPT is an extension of the MMU page tables that are controlled by the Monitor in EL3. The new GPT maps each table in memory to one of the four worlds. On each memory access attempt, a new Granule Protection Check takes place ensuring only permitted accesses are allowed. Invalid accesses trigger page faults. Note that any memory assigned to the Normal, Secure, Root, and Realm world is encrypted by the hardware prior to written to DRAM.

Realm Management Monitor (RMM)

As part of the Arm CCA, a new firmware/software architecture is also defined. A new Realm Management Monitor (RMM) is defined which provides services for the hypervisor as well as to the realms themselves. This is done via a new Realm Management Interface (RMI). Services for the hypervisor include the creation and destruction of realms as well as adding and removing memory. Additionally, realms can also request attestation reports via the RMI which can be for the platform or the realm which can be presented to a requesting party.