On TrustZone & Arm CCA
Our model sealing runs on TrustZone. We reposted last week an article from Trail of Bits, that ended with two attacks with catastrophic consequences: a live read of DRAM, and a kernel 0-day. Both are limits of TrustZone itself, and Arm has had the fix on paper since 2021: the Confidential Compute Architecture, CCA.
We have been reading that specification for a while, and it is the hardware we most want to get our sealing onto. This post is about what CCA is, what it changes, and when you can expect to buy it.
Where TrustZone comes from
Arm announced TrustZone in October 2003, with the ARM1176 cores. The problem it solved was a phone problem: an open operating system anyone could write software for, next to a handful of things the operator did not want that software anywhere near. SIM logic, DRM, later payments and fingerprints. The answer was not a second chip. It was a second mode for the same one.
How TrustZone works
A TrustZone CPU runs in one of two states, secure or normal. Same core, same instructions, same speed; only the state differs. Every time the CPU reads memory or talks to a peripheral, the request carries that state with it, so the rest of the chip knows who is asking.
Memory and peripherals use that to say no. A small controller in front of the RAM holds a list of address ranges marked secure-only and drops any request arriving from the normal state. The same gate sits in front of the crypto engine, the fingerprint sensor, the fuses holding the device’s root keys. From the normal state, those addresses simply do not respond.
The two states run two operating systems. The normal world gets the big one, Linux or Android, with its drivers and its network stack and everything anyone has ever installed on it. The secure world gets a small one whose whole job is to keep a few secrets and do a few operations with them; we use OP-TEE, the open-source one. A normal-world program never touches a secret. It asks the secure world to decrypt this or sign that, and gets the answer back. The key stays on the other side. A tiny piece of firmware, the monitor, flips between the two states thousands of times a second.
In our system the keys live in the secure world and never leave it. A trusted application unwraps the per-device key and decrypts the model, and a kernel module lets only signed binaries read the result. Root cannot. That holds on every board we have tried, across five silicon vendors.
What TrustZone assumes
Three assumptions are built in, and all three come from the 2003 phone.
One secure world is enough. Every trusted application from every vendor, the payment one, the DRM one, ours, shares the same small OS and trusts it completely.
The normal-world OS is trusted with whatever it handles. Anything that crosses back from the secure world, the unlocked content, the result of the computation, sits in memory the normal OS can read, and so can anyone who takes that OS over.
Memory is private because it is inside the phone. The controller filters by address; it does not encrypt the bits in the chips. Pull the RAM or probe the bus, and secure and normal memory read equally well.
Where CCA comes from
Servers hit the same three assumptions first, and harder: a cloud customer wants to run a workload without trusting the provider’s operating system, on a machine shared with thousands of strangers. Intel and AMD answered with SGX, then SEV-SNP and TDX, virtual machines whose memory is encrypted and which the host cannot look into.
Arm’s version is the Confidential Compute Architecture, CCA, introduced with Armv9 in 2021. Its hardware half is the Realm Management Extension.
How CCA works
CCA keeps TrustZone’s two states and adds two more: normal, secure, realm and root.
Root is the smallest. It holds the monitor and a table, the Granule Protection Table, with one entry per page of physical memory saying which of the four states owns it. The hardware consults that table on every memory access, from the CPU and from every peripheral, and refuses requests from the wrong state. TrustZone’s filter was a short list of ranges fixed at boot. This is a page-by-page map that changes at runtime.
Realm is where workloads go. A Realm is a small virtual machine. The normal-world OS still creates it, gives it memory and schedules it, as it would any VM. What it can no longer do is read that memory: the moment a page is handed to a Realm, the table flips and the OS is locked out of its own gift. A very small piece of software, the Realm Management Monitor, keeps the Realms apart from each other. It is not a hypervisor; it only checks that the hypervisor’s requests are legal.
Two pieces finish the picture. Memory Encryption Contexts, a companion extension, give each Realm its own key at the memory controller, so its pages are ciphertext in the chips and a probe on the bus reads noise. And a Realm can ask the hardware for a signed receipt, an attestation token, listing exactly what was loaded into it. A server on the other side of the world can check that receipt before handing over a secret.
What changes
Set the three assumptions next to it. No more single shared room: each workload gets its own, and they trust neither each other nor the OS. The OS is no longer trusted with what it handles, because it handles the memory without being able to read it. And memory is no longer private by being inside the box, because it is encrypted per Realm.
The secure world does not go away. OP-TEE and its trusted applications are still there; Realms sit beside them, not in place of them. For a model sealed on a device, a Realm is the natural next home: decrypt inside it, run inside it, release the key only to a Realm whose receipt matches what we signed at build time. How accelerators join a Realm is still being written into the specification, and it is the part we watch most closely.
When
Software first. Linux has run as a Realm guest since 6.14. The other half, KVM creating and running Realms, is at its fourteenth revision, posted in May, rebased on 7.1 and targeting the second version of the RMM specification, with the reference RMM being brought up to that version alongside it, but it is not in a mainline kernel as of today.
Hardware second. The Realm Management Extension is optional from Armv9.2, so it arrives core by core. So far it has shipped in server cores, Neoverse V3 among them. On the edge I know of no SoC with it yet, which is the usual order: on x86 too, the equivalents were server features first, and smaller parts followed a few years behind.
Until a board exists there is Arm’s Fixed Virtual Platform, QEMU, and OpenCCA from ETH Zurich, which patches the whole software stack to emulate Realms on a $250 Rockchip board. Our plan is simple: the decrypt-and-run path moves into a Realm when the silicon lands, and TrustZone stays for everything else.