Abstract

Arm’s Confidential Compute Architecture (CCA), introduced with the Armv9.2 specification and landing in silicon with Cortex-A720 derivatives shipping through 2024-2025, is one of the more architecturally ambitious attempts to push trusted execution beyond the enclave-per-process model of TrustZone. The key primitive is the Realm, a hardware-isolated VM whose memory is encrypted and integrity-protected even from the host hypervisor and from Arm’s own Secure world. This post examines the microarchitectural mechanisms that underpin Realm isolation, the attestation model they enable, and the practical constraints that cloud providers face when deploying CCA-capable hardware.

Physical Address Space Partitioning and the Realm Management Monitor

CCA introduces a new execution level called the Realm Management Monitor (RMM), sitting at EL2 in the Realm world alongside the guest OS, separate from the Normal world hypervisor at EL2. The hardware enforces this separation through a Granule Protection Table (GPT), a two-level structure maintained by the Root Monitor at EL3. Each 4 KB granule in physical memory is tagged as belonging to one of four states: Normal, Realm, Secure, or Root. Attempts by a Normal-world hypervisor to access Realm-tagged memory raise a Granule Protection Fault. The tagging is enforced in hardware by the System MMU and the interconnect, so it cannot be bypassed by a compromised hypervisor even if it controls the Normal-world page tables. Qualcomm’s Oryon cores and Nvidia’s Grace CPU implement the Armv9 GPT hardware as of their respective 2024 tape-outs, with server deployments ramping through early 2025.

Memory Encryption and the Realm Attestation Chain

Realm memory is encrypted at the memory controller level using per-Realm keys managed by the RMM. Key provisioning happens through a boot-time attestation flow: the hardware Root of Trust measures the RMM firmware, the hypervisor delegates Realm creation via an RMM call, and the RMM issues a Realm Attestation Token (RAT) conforming to the IETF RATS (Remote Attestation Procedures) architecture. A workload operator verifying a Realm receives a token that covers the initial measurement of the Realm image, the hardware platform identity, and the RMM version. This chain is structurally similar to Intel TDX’s TD Quote but differs in that the RMM is a standardized Arm specification component rather than a vendor-specific firmware module, making cross-vendor attestation verification more tractable. The Veraison project under the Confidential Computing Consortium has prototype verifier support for CCA RATs as of mid-2025.

Microarchitectural Side-Channel Considerations

CCA does not, by design, attempt to eliminate cache timing channels between Realms sharing a physical core. The threat model assumes a malicious hypervisor, not a malicious co-tenant executing on the same core. Realms share L1 and L2 caches with Normal-world workloads during time-sliced execution. For workloads that require co-tenant isolation, the expectation is that cloud providers enforce core pinning policies at the scheduler level, similar to how AMD SEV-SNP deployments today often dedicate physical cores to sensitive VMs. Flush-on-context-switch mitigations analogous to Linux’s x86 IBRS handling will likely become part of the RMM reference implementation specification as deployments scale.

Deployment Status

As of mid-2025, CCA-capable hardware is in customer-facing cloud trials at at least two hyperscale providers, with AWS Graviton and Google Axion both following Armv9.x roadmaps that include CCA features in forthcoming revisions. The open-source RMM reference implementation is available under the Apache 2.0 license from Arm’s GitHub and is the baseline that most platform vendors are forking.