Last March, in a clear effort to differentiate its processor features from x86, as part of its version 9 architecture, Arm Limited introduced its concept of realms — isolated regions of the processor where threads are fully encrypted, and inaccessible by other threads. On Wednesday, the licensor of semiconductor IP published the technical specifications for Realms (capital “R”) as the foundation for what the company now calls Arm Confidential Compute Architecture (CCA).
The firm’s goal: rendering critical system processes unexploitable by outside code.
“We believe that secure computing needs to be accessible for all developers,” explained Mark Knight, Arm’s director of architectural product management, speaking with Data Center Knowledge. “We’re really looking to democratize secure computing. We want to extend the kind of high-trust environments that have previously, mainly been accessible to silicon partners and OEMs, to all developers. So we’ve created a new, high-trust security environment.”
A realm is an environment in the sense that it’s a cordoned-off area of the processor, capable of executing threads without being tampered with by other threads outside that environment. By contrast, a software-based container (e.g., Docker) was originally intended as an isolated area of memory whose namespace isn’t shared with the rest of the system. At the time containers were introduced, Docker and their other champions touted their security by saying, since processes outside a container couldn’t address its contents by name or by network address, they may as well not exist.
That explanation got holes poked in it almost immediately. A real barrier for protecting processes in true isolation, argued security engineers, would require hardware-based enforcement. That’s what a realm would be: an enclave for processes that must be impenetrable to be reliable.
World #3
As Arm Chief Architect Richard Grisenthwaite explained in March, a process that utilizes secrets or other sensitive data could be entrusted to an Arm core’s secluded realm. This way, an Arm-based device such as a mobile phone could be entrusted to any user at all, without the IT department having to place access restrictions on the app utilizing those secrets — the realm is restrictive enough. Should the device get lost or even stolen, those secrets would be just as protected as if they were buried in the core of an asteroid.
“The architecture we have provides strong protection between mutually distrusting workloads running within realms,” explained Arm’s Knight, “protection against compromised rich operating systems such as Linux, or a Normal world hypervisor; and for the first time, we’re also protecting these sensitive, ‘realmed’ workloads from applications running in the Secure world.”
“Normal world” and “Secure world” are references to two concepts in Arm’s existing Trusted Execution Environment (TEE) in Armv8.4-A architecture. They have to do with Arm’s earlier method of partitioning processes that can be expected to access foundational resources such as the operating system and drivers (Normal), from other processes whose access to those resources may require intervention (Secure). An ordinary hypervisor may manage resources for applications and processes in the Normal world, whereas an Arm resource called the Secure Partition Manager ensured that the address spaces of processes in the Secure world were inviolable from the Normal world.
This type of working relationship was fine for resources that built on top of the foundational layers of software, forming “stacks,” if you will — for software designed to share functionality. But it didn’t work as well for third-party applications to which, if we’re being practical, the operating system itself should not have unsecured access. Realms let software developers build enclaves for themselves, protected from malware and other intrusion that would exploit faults in the operating system, to gain unprivileged access to their code and data.
Containers already provide one security boundary through namespace isolation. Hypervisors provide an additional security boundary by way of keeping VMs’ network overlays disconnected from one another. Then, for many Arm-based devices up to now, there’s TEE environments. So why aren’t all three of these boundaries good enough? Can’t we accomplish what Realms sets out to achieve, without creating another security boundary?
“The simple answer is, what you said is largely true,” responded Knight, “but it relies on the perfect implementation of the operating system that is supporting, and providing isolation between, those namespaces. And it’s very hard to assure that level of goodness of implementation. You’re only potentially one bug away from having data accessible from a place you didn’t want it to be.”
Data In Use
Isn’t there — or wouldn’t there be, in the near future — a potentially exploitable policy defect in enabling encryption only for code and material that users believe, or declare to be, confidential? Put another way, doesn’t the very declaration of confidentiality open up vulnerabilities for digital assets that fall through the policy cracks? Shouldn’t policy, instead, eventually encrypt everything — protecting all digital assets by making them all eligible for dwelling within realms?
“I think that’s the vision,” responded Arm’s Mark Knight. “If you look at encryption, typically, you have to take a fairly surgical approach.” For data at rest, he explained, it makes sense to encrypt all of it — the whole database, or perhaps the entire volumes on which it’s stored. A fine-grained policy becomes difficult, because it requires policy makers to better comprehend the inner behavior of applications, and the intent of its developers — which is harder to do when those applications are years, maybe decades, old. For data in transit, the problem is already solved: use TLS to encrypt the link.
“Protecting data in use, it’s tougher,” he continued. “It requires a bigger investment in software engineering. And I think the beauty with technologies like Realms is that many workloads have already been virtualized, and we see virtualization-based security in platforms like Windows, where services like key stores are already migrating their way into the micro-VMs. This technology supports that journey by helping to remove that dependency on a perfect implementation of the hypervisor, because now we’re just taking the hypervisor out of scope too. It’s something that’s relatively easy for organizations to adopt. Certainly VMs could run within a realm with almost no modification.”
With the publication of CCA specifications for Armv9 today, expect the dissemination of Realms-supporting applications on Arm processors, Knight told us, within a few years’ time. Why so long?
“We start by sharing the architecture, which we develop in partnership with many of our partners,” he answered, “and there’s quite an intuitive process to get that accurate and right. Then, of course, we have to have quite complex things like compliance suites to ensure our partners can verify their implementations — or indeed, if they license implementations from us, that they’re accurate.”
From there, he said, the actual implementation process itself consumes some time. Licensees do have the freedom, he noted, to create their own implementations. Next, getting the production cycle of processors through the fabricators — a process that is already being slowed down by recovery from the pandemic. And finally, integrating those fabricated processors into consumable products.
“There’s a whole series of steps we need to go through,” said Knight. “Sharing the architectural specs is, in some ways, the beginning of that journey.”
