Arm Confidential Compute Architecture: Realms, RME, and attestation
Arm CCA defines a Realm security state isolated from both the Normal and Secure worlds. It is an architecture and ecosystem; availability and physical protections depend on the implementation.
Direct answer
Arm CCA uses Realm Management Extension to add Realm and Root security states. A Realm Management Monitor isolates Realms and supports attestation while an untrusted host continues to schedule resources and emulate complex devices. The implemented platform—not the architecture name alone—determines memory encryption, device assignment, side-channel, and availability properties.Realm and Root security states
Realm Management Extension adds Realm and Root alongside Arm’s existing Normal and Secure states. Realms are isolated from software in both Normal and Secure worlds. Root remains the most privileged state and is part of the platform trust dependency.STATES
The Realm Management Monitor
The Realm Management Monitor runs at Realm EL2, manages the Realm boundary, and supplies attestation-related services. The normal-world host retains scheduling, allocation, interrupts, and complex device emulation. That separation aims to keep the security monitor smaller while allowing existing host infrastructure to manage resources.RMM
| Component | Role | Trust implication |
|---|---|---|
| Realm | Protected guest execution state | Guest application/kernel remain inside the Realm TCB |
| RMM | Creates, isolates, measures, and manages Realms | A critical trusted component |
| Root/EL3 firmware | Platform root management and security services | Remains trusted |
| Normal-world host | Scheduling, allocation, I/O orchestration | Untrusted for confidentiality/integrity but still controls availability |
| Accepted devices | Optional direct device participation | Need platform and device attestation/assignment support |
Realm attestation and device assignment
CCA attestation evidence covers relevant initial Realm and platform state so a relying party can evaluate the environment. Device access to Realm memory is denied by default. Newer device-assignment architecture uses device attestation and TDISP-style isolation before a Realm consents to direct access.EVIDENCEDEVICE
What the architecture does not establish by itself
- Cloud or server availability: a named provider must ship and support a concrete CCA implementation.
- Denial-of-service resistance: the host still schedules and supplies resources.
- Universal memory-encryption or physical-attack properties: these depend on the system implementation and CCA version.
- Automatic device confidentiality: direct device assignment requires compatible platform and device isolation/attestation.
- Guest correctness: vulnerable code and unsafe outputs remain inside the Realm’s trusted computing base.
- Complete side-channel resistance: platform-specific analysis is still required.
Frequently asked questions
Is Arm CCA a cloud product?
No. It is an architecture that hardware, firmware, operating-system, hypervisor, and cloud vendors implement. A buyer must verify a concrete supported platform and evidence path.
Can the host still control a Realm?
The normal-world host still schedules and allocates resources and can deny service. RME/RMM aim to prevent that host from reading or silently altering protected Realm state within the documented boundary.
Can devices directly access Realm memory?
They are denied by default. Supported direct assignment requires compatible platform/device isolation and attestation mechanisms, and the Realm must consent to the device.
Sources
- STATES
- RMM
- MODEL
- DEVICE
- EVIDENCE
Relevant GPU availability
Verified specifications, confidential-mode support, and public listings for the accelerators this post covers.
Ready to reserve capacity?
Confidential Nodes matches bare-metal confidential GPU nodes to workloads, with verified provider data behind every listing.