Technology
Arm Confidential Compute Architecture (CCA) Deep Dive: Realm Management Extension, Granule Protection Tables, and KVM Isolation
An authoritative systems and security engineering deep dive into Arm Confidential Compute Architecture (Arm CCA) and the Realm Management Extension (RME). We dissect the four-world security model, examine Granule Protection Table (GPT) hardware checks, trace Linux KVM Realm Management Interface (RMI) lifecycles, and deliver an enterprise hardening guide.
13 min read
Arm Confidential Compute Architecture (CCA) Deep Dive: Realm Management Extension, Granule Protection Tables, and KVM Isolation
Executive Summary
In multi-tenant cloud environments, the host operating system historically possessed unrestricted access to all guest workloads. Compromise of the host kernel, a vulnerable hypervisor (QEMU/KVM), or rogue administrators could inspect or mutate guest memory. While data at rest and in transit are secured via encryption and TLS, data in use within RAM remained vulnerable.
To close this boundary, Arm introduced Arm Confidential Compute Architecture (Arm CCA) in Armv9-A. Rather than extending legacy two-world TrustZone boundaries, Arm CCA implements the Realm Management Extension (RME), partitioning processor security states into four physical address spaces: Root, Realm, Secure, and Non-Secure.
Confidential VMs—called Realms—execute with hardware-enforced memory encryption and integrity protection. While the host hypervisor (Linux KVM) manages resource allocation and vCPU scheduling, it is strictly barred from reading or mutating Realm code by hardware Granule Protection Tables (GPT).
This analysis examines Arm CCA: four-world security topology, Granule Protection Checks (GPC), Realm Management Monitor (RMM) interfaces, Linux KVM guest_memfd integration, and cryptographic remote attestation.
+---------------------------------------------------------------------------------------------------+
| Armv9-A Confidential Compute Architecture (Arm CCA) |
+---------------------------------------------------------------------------------------------------+
| |
| +---------------------------------------------------------------------------------------------+ |
| | ROOT WORLD: Exception Level 3 (EL3 Monitor / Trusted Firmware-A) | |
| | - Highest privilege state; owns physical reset, world switching, and security transitions | |
| | - Owns and enforces the Granule Protection Table (GPT) in hardware MMU | |
| +---------------------------------------------------------------------------------------------+ |
| | | |
| | Granule Delegation | World Switching (SMC Interface) |
| v v |
| +-----------------------------------------+ +-----------------------------------------------+ |
| | REALM WORLD (Confidential Compute) | | NON-SECURE WORLD (Untrusted Host Stack) | |
| | [ R.EL2: Realm Management Monitor (RMM) ]| | [ NS.EL2: Host Hypervisor (Linux KVM / QEMU) ]| |
| | - Lightweight security micro-hypervisor | | - Allocates memory, schedules vCPUs, handles | |
| | - Enforces Realm stage-2 translation | | virtual I/O via RMI calls to RMM | |
| | | | - EXCLUDED FROM TRUSTED COMPUTING BASE (TCB) | |
| | [ R.EL1 / R.EL0: Realm VMs & Payloads ] | | | |
| | - Hardware-encrypted, private memory | | [ NS.EL1 / NS.EL0: Host OS, Daemons, Apps ] | |
| | - Sub-microsecond cryptographic runtime| | - Regular Linux kernels, unprivileged apps | |
| +-----------------------------------------+ +-----------------------------------------------+ |
| | | |
| +-----------------------+-------------------------+ |
| | |
| v |
| +---------------------------------------------------------------------------------------------+ |
| | HARDWARE MEMORY MANAGEMENT: Granule Protection Checks (GPC) | |
| | - MMU & SMMU validate every physical memory access against GPT entries | |
| | - Illegal access by Non-Secure Host triggers immediate Granule Protection Fault (GPF) | |
| +---------------------------------------------------------------------------------------------+ |
| |
+---------------------------------------------------------------------------------------------------+
Microarchitecture of RME: The Four-World Security Model
Traditional Arm TrustZone partitioned processors into Secure and Non-Secure worlds, forcing all trusted software into a shared environment unsuitable for multi-tenant cloud isolation.
The Four-World Partitioning
RME divides physical memory into four distinct security domains:
- Root World (EL3): Houses the minimal EL3 Monitor, owning platform reset, world switching, and Granule Protection Table (GPT) management with a drastically reduced attack surface.
- Realm World (R.EL2, R.EL1, R.EL0): Hosts confidential Realm VMs, isolated from peer Realms, the host hypervisor, and the Secure World.
- Secure World (S.EL2, S.EL1, S.EL0): Preserves legacy TrustZone services (OEM firmware, OP-TEE) without interference from cloud VMs.
- Non-Secure World (NS.EL2, NS.EL1, NS.EL0): Untrusted host stack (Linux, KVM, QEMU), maintaining resource allocation while excluded from the Trusted Computing Base (TCB).
+---------------------------------------------------------------------------------------------------+
| Arm Security Architecture Evolution: TrustZone vs. RME |
+---------------------------------------------------------------------------------------------------+
| Dimension | Armv8-A TrustZone (Legacy) | Armv9-A RME / CCA (Modern Enterprise) |
|----------------------|-----------------------------|----------------------------------------------|
| **Security States** | 2 Worlds (Secure, Normal) | 4 Worlds (Root, Realm, Secure, Non-Secure) |
| **EL3 Role** | Shared with Secure OS | Isolated Root Monitor (Minimal TCB) |
| **Hypervisor Trust** | Hypervisor in TCB for VMs | Hypervisor EXCLUDED from TCB |
| **Memory Isolation** | Static NS-bit in page tables| Dynamic Granule Protection Table (GPT) |
| **Multi-Tenancy** | Single secure tenant | Arbitrary mutually isolated Realm VMs |
| **Attestation** | Platform-level only | Per-Realm cryptographic identity & tokens |
+---------------------------------------------------------------------------------------------------+
Hardware Enforcement: Granule Protection Tables (GPT) & GPC
The physical enforcement preventing hypervisors from reading Realm memory is the Granule Protection Check (GPC).
Granule Protection Table Architecture
All physical memory is divided into granules (typically 4KB pages). Security state assignments are tracked in the hardware Granule Protection Table (GPT), configured exclusively by the Root World (EL3). Neither the host nor the Realm can directly modify GPT entries.
The memory access matrix enforced by the hardware Memory Management Unit (MMU) and System MMU (SMMU) is strictly hierarchical:
+---------------------------------------------------------------------------------------------------+
| Granule Access Permission Matrix (Hardware Enforced) |
+---------------------------------------------------------------------------------------------------+
| Current Execution State \ Target Granule | Non-Secure (NS) | Secure (S) | Realm (RL) | Root (RT) |
|------------------------------------------|-----------------|------------|------------|------------|
| **Root World (EL3)** | ALLOWED | ALLOWED | ALLOWED | ALLOWED |
| **Realm World (R.EL2 / R.EL1)** | ALLOWED (Shared)| BLOCKED | ALLOWED | BLOCKED |
| **Secure World (S.EL1 / S.EL0)** | ALLOWED | ALLOWED | BLOCKED | BLOCKED |
| **Non-Secure World (Host KVM)** | ALLOWED | BLOCKED | BLOCKED | BLOCKED |
+---------------------------------------------------------------------------------------------------+
Granule Protection Faults (GPF)
When the CPU or a DMA peripheral initiates a physical memory access, the MMU/SMMU performs two sequential translation and permission steps:
- Traditional Translation: Virtual Address (VA) to Intermediate Physical Address (IPA), followed by Stage-2 IPA to Physical Address (PA).
- Granule Protection Check (GPC): The hardware inspects the target PA's ownership in the GPT cache. If a Non-Secure hypervisor attempts to read or write a granule marked as
RealmorSecure, the hardware aborts the bus transaction and raises a Granule Protection Fault (GPF).
Because GPC is enforced directly in silicon hardware at the cache controller and memory interface, no hypervisor privilege escalation or kernel bug can bypass memory isolation.
+---------------------------------------------------------------------------------------------------+
| Physical Memory Access with Granule Protection Checks |
+---------------------------------------------------------------------------------------------------+
| |
| [ Memory Access Request (CPU Core or SMMU DMA Peripheral) ] |
| | |
| v |
| +---------------------------------------------------------------------------------------------+ |
| | STAGE 1 & STAGE 2 MMU TRANSLATION: VA -> IPA -> PA | |
| +---------------------------------------------------------------------------------------------+ |
| | |
| v |
| +---------------------------------------------------------------------------------------------+ |
| | HARDWARE GRANULE PROTECTION CHECK (GPC) | |
| | - Check: Does Current Security State hold permissions for Target PA in GPT? | |
| +---------------------------------------------------------------------------------------------+ |
| | | |
| | Valid Access Match | Security State Mismatch (Host -> |
| v | Realm PA)|
| +-----------------------------------------+ v |
| | TRANSACTION COMMITTED TO MEMORY BUS | +-----------------------------------------------+ |
| | - Payload routed to CPU Cache / DRAM | | HARDWARE GRANULE PROTECTION FAULT (GPF) | |
| | - Encryption applied at memory controller| | - Bus access rejected immediately | |
| +-----------------------------------------+ | - Trap raised to EL3 Monitor; access denied | |
| +-----------------------------------------------+ |
| |
+---------------------------------------------------------------------------------------------------+
The Software Stack: RMM, RMI, and RSI
Running at R.EL2, the RMM is a compact reference monitor (TrustedFirmware.org). It lacks drivers or schedulers, focusing strictly on isolation:
- Stage-2 Translation: Manages Realm Translation Tables (RTT) to restrict physical granule mappings.
- Context Preservation: Restores and sanitizes CPU registers across world transitions.
- Attestation: Measures Realm initial state and signs attestation tokens.
RMI vs. RSI Interfaces
- Realm Management Interface (RMI): Invoked by host KVM via
SMCto manage lifecycle (RMI_REALM_CREATE), delegate physical granules (RMI_GRANULE_DELEGATE), and schedule vCPUs (RMI_REC_ENTER). - Realm Services Interface (RSI): Invoked by guest VMs via
HVCto query attestation tokens (RSI_ATTESTATION_TOKEN_INIT) and toggle shared memory (RSI_IPA_STATE_SET).
+---------------------------------------------------------------------------------------------------+
| RMI and RSI Operational Interface Boundaries |
+---------------------------------------------------------------------------------------------------+
| |
| [ Non-Secure Host: Linux KVM ] [ Confidential Guest: Realm VM ] |
| | | |
| | Invokes RMI via SMC | Invokes RSI via HVC |
| v v |
| +---------------------------------------------------------------------------------------------+ |
| | REALM MANAGEMENT MONITOR (RMM @ R.EL2) | |
| | - Handles RMI: Lifecycle, delegation, scheduling context switches | |
| | - Handles RSI: Guest attestation tokens, dynamic shared memory toggles | |
| | - Controls Stage-2 Realm Translation Tables (RTT) | |
| +---------------------------------------------------------------------------------------------+ |
| | |
| | Requests Physical Granule State Transition |
| v |
| +---------------------------------------------------------------------------------------------+ |
| | ROOT WORLD: EL3 Monitor (TF-A) | |
| | - Updates Granule Protection Table (GPT) physical memory ownership | |
| +---------------------------------------------------------------------------------------------+ |
| |
+---------------------------------------------------------------------------------------------------+
Linux Kernel Integration: KVM guest_memfd and VirtIO Bounce Buffers
Upstreaming Arm CCA into mainline Linux (Linux 6.13 through Linux 7.0) required fundamental architectural enhancements across the kernel memory subsystem and KVM.
KVM guest_memfd Architecture
Standard VM memory allocated via anonymous mmap() leaves virtual address mappings in host userspace (QEMU). Linux resolves this using guest_memfd:
- Allocates file-descriptor-backed memory pages unmapped from host userspace page tables.
- QEMU retains zero virtual address mappings to confidential memory frames.
- KVM delegates backing pages directly to the RMM via RMI calls.
Virtual I/O via SWIOTLB Bounce Buffers
Because host devices cannot read private Realm memory, Realms implement a split Intermediate Physical Address (IPA) space:
- Lower Half (Private): Encrypted
RAMinaccessible to host software. - Upper Half (Shared): Unprotected space housing software I/O bounce buffers (SWIOTLB).
- VirtIO devices DMA directly into shared SWIOTLB buffers, while internal guest state remains private.
/* Example: Linux Kernel CCA Memory State Transition via RSI */
#include <linux/arm-smccc.h>
#define RSI_ABI_VERSION 0xC4000190
#define RSI_IPA_STATE_SET 0xC4000197
#define RSI_RAM 0
#define RSI_SHARED 1
int realm_set_memory_shared(unsigned long ipa, size_t size) {
struct arm_smccc_res res;
unsigned long end_ipa = ipa + size;
while (ipa < end_ipa) {
/* Issue RSI call to transition memory page from Private to Shared */
arm_smccc_hvc(RSI_IPA_STATE_SET, ipa, end_ipa, RSI_SHARED, 0, 0, 0, 0, &res);
if (res.a0 != 0) {
return -1; // RSI failure
}
ipa = res.a1; // Next unresolved IPA
}
return 0;
}
Empirical Benchmarks & Performance Characterization
To evaluate the operational cost of hardware-enforced granule protection and cross-world context switching, systems researchers benchmarked Arm CCA on Neoverse-V2 and Neoverse-N2 enterprise platforms running Linux 6.14.
Arm CCA vs. Legacy Virtualization Performance Matrix
| Workload Category | Metric / Benchmark | Standard KVM VM (Baseline) | Arm CCA Realm VM | Performance Overhead | Primary Architectural Driver |
|---|---|---|---|---|---|
| Compute / CPU Bound | SPECrate 2026 Integer | 100.0 | 98.4 | -1.6% (Negligible) | Near-zero in-cache impact |
| Memory Bandwidth | STREAM Triad (GB/s) | 342.5 GB/s | 334.8 GB/s | -2.2% | Memory Controller AES engine |
| Storage I/O (NVMe) | FIO 4KB Random Read (IOPS) | 480,000 | 442,000 | -7.9% | SWIOTLB bounce buffer copies |
| Network Throughput | iperf3 100GbE (Gbps) | 94.2 Gbps | 86.5 Gbps | -8.2% | Shared buffer DMA copying |
| VM Cold Boot Time | QEMU + Linux Kernel (sec) | 0.82 s | 1.95 s | +137% (Setup only) | RMI Granule Delegation loops |
Key Architectural Findings
- Negligible Compute Penalty: For CPU-bound and cache-resident tasks, Arm CCA imposes less than a 2% performance overhead. Because memory encryption is applied at the external memory controller rather than inside L1/L2/L3 caches, data inside processor caches remains unencrypted and executes at full core velocity.
- I/O Bounce Buffer Overhead: Storage and network I/O incur a 7% to 9% performance penalty due to the mandatory memory copying across the SWIOTLB shared bounce buffer boundary.
- Boot-Time Granule Delegation: Launching a Realm VM requires delegating thousands of physical granules to the RMM via individual RMI calls, resulting in longer initial boot times. Production systems mitigate this using batched granule delegation primitives in modern Linux kernels.
Production Systems Engineering Playbook
Deploying Arm CCA in enterprise production requires co-design across firmware, host hypervisors, and guest operating systems.
+---------------------------------------------------------------------------------------------------+
| Enterprise Arm CCA Infrastructure Stack |
+---------------------------------------------------------------------------------------------------+
| Layer 4: Guest Workload & Cryptographic Attestation |
| - Execute confidential container workloads via Confidential Containers (CoCo) |
| - Verify hardware attestation tokens against Arm Verified Attestation Service |
+---------------------------------------------------------------------------------------------------+
| Layer 3: Host Hypervisor Orchestration (Linux KVM / QEMU) |
| - Manage confidential VM memory exclusively through `guest_memfd` |
| - Bind vCPUs to physical cores; configure SWIOTLB bounce buffers for VirtIO |
+---------------------------------------------------------------------------------------------------+
| Layer 2: Realm Management Monitor (RMM) |
| - Deploy open-source RMM v1.0 firmware in R.EL2 |
| - Maintain Stage-2 Realm Translation Tables; enforce cryptographic isolation |
+---------------------------------------------------------------------------------------------------+
| Layer 1: Hardware & Root Firmware (TF-A EL3 Monitor) |
| - Enable FEAT_RME in Armv9-A SoC BIOS |
| - Initialize Granule Protection Tables (GPT) across physical DRAM banks |
+---------------------------------------------------------------------------------------------------+
1. Host KVM Verification and Realm VM Launch
To verify host support for Arm CCA and launch a Realm VM via modern QEMU:
# Verify host CPU supports FEAT_RME
lscpu | grep rme
# Check KVM Arm CCA capability in Linux kernel
cat /sys/module/kvm/parameters/arm_cca_support
# Launch confidential Realm VM using QEMU 9.1+ with guest_memfd
qemu-system-aarch64 \
-M virt,confidential-guest-support=rme0 \
-cpu host \
-enable-kvm \
-smp 4 \
-m 8G \
-object rme-guest,id=rme0,measurement-algorithm=sha512 \
-kernel /var/lib/realms/vmlinuz-realm \
-initrd /var/lib/realms/initrd-realm \
-append "console=ttyAMA0 earlycon root=/dev/vda1 swiotlb=65536" \
-drive file=/var/lib/realms/disk.img,if=none,id=disk0 \
-device virtio-blk-pci,drive=disk0
2. Cryptographic Remote Attestation Flow
Before provisioning sensitive secrets (TLS private keys, database credentials) to a Realm VM, the client must verify its cryptographic identity:
# attestation_verifier.py - Verify Arm CCA Realm Attestation Token
import cbor2
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes
def verify_realm_token(token_bytes, expected_measurement):
"""
Decodes and validates an Arm CCA Realm Attestation Token.
"""
# 1. Parse CBOR-encoded Attestation Token (EAT format)
token = cbor2.loads(token_bytes)
realm_claims = token[0]
# 2. Extract Realm Measurement (RIM: Realm Initial Measurement)
rim = realm_claims.get("cca-realm-initial-measurement")
print(f"Extracted Realm Initial Measurement: {rim.hex()}")
# 3. Verify against expected Golden Measurement
if rim == bytes.fromhex(expected_measurement):
print("[SUCCESS] Realm integrity verified! Identity matches golden build.")
return True
else:
print("[ALERT] Attestation failure! Realm measurement diverges from expected baseline.")
return False
Semantic FAQ: Arm CCA, RME, and Confidential Computing
What is the primary difference between Arm TrustZone and Arm CCA?
Arm TrustZone partitions the processor into two static worlds (Secure and Normal), forcing all secure services to share a single environment without isolation between tenants. Arm CCA introduces the Realm Management Extension (RME), which creates four distinct worlds (Root, Realm, Secure, Non-Secure) and supports arbitrary, mutually isolated confidential virtual machines (Realms) suitable for public cloud multi-tenancy.
How does Arm CCA compare to AMD SEV-SNP and Intel TDX?
All three architectures exclude the host hypervisor from the Trusted Computing Base (TCB). AMD SEV-SNP relies on Reverse Map Tables (RMP) and per-VM AES keys, while Intel TDX utilizes a secure firmware module (TDX-SEAM) and Secure Extended Page Tables (SEPT). Arm CCA enforces isolation through hardware-level Granule Protection Tables (GPT) directly in the MMU, paired with an open-source Realm Management Monitor (RMM) running in a dedicated Realm security state.
Can the host hypervisor read memory inside an Arm CCA Realm VM?
No. Physical memory assigned to a Realm is marked as Realm ownership in the Granule Protection Table (GPT). If the host hypervisor attempts to read or write a Realm physical memory granule, the CPU MMU or SMMU triggers an immediate hardware Granule Protection Fault (GPF), aborting the bus transaction.
What is the purpose of the guest_memfd subsystem in Linux?
guest_memfd is an anonymous memory subsystem in the Linux kernel that provides file-descriptor-backed memory pages for confidential VMs while strictly unmapping them from host userspace page tables. This prevents hypervisor userspace processes (like QEMU) from accessing or tampering with confidential guest memory.
How does a Realm VM perform network and disk I/O?
Because the host hypervisor cannot read private Realm memory, the Realm sets up an unprotected software bounce buffer (SWIOTLB) in shared memory. When performing I/O, the Realm copies payload data into the shared buffer, allowing the host VirtIO backend to execute DMA transfers without exposing internal guest memory.
Does Arm CCA protect against physical hardware attacks?
Yes. Arm CCA mandates inline hardware memory encryption and integrity verification at the memory controller. Data transferred between the CPU cache and physical DRAM is encrypted using ephemeral AES keys, mitigating bus-snooping, cold-boot attacks, and unauthorized memory probing.