Making It Easier To Build Platforms That Support Confidential Computing

With the rise of the cloud, computation has become highly distributed. Workloads can be running on many compute nodes and often span multiple data centers. A workload consists of a combination of code and data, and both are often valuable and sensitive. A data center is often managed by a third-party, such as Cloud Service Provider (CSP), and may reside in a different legal jurisdiction to the workload’s owner. The need to host increasingly sensitive workloads in the cloud has driven the need for Confidential computing. This is a model where a workload can be deployed on third-party infrastructure, with a high degree of confidence that no third party can compromise its confidentiality nor its integrity.

While today this model is most often used to describe properties that are desirable in a public cloud, there is growing interest in several other markets. Modern vehicle design seeks to consolidate multiple workloads from different suppliers onto a single in-car server. The consumerization of IT has led to a mix of personal and corporate data on personal computers. These are both examples of applications that have similar security requirements to the public cloud, and where the same underlying security technologies can be reused.

Several challenges must be solved to construct a platform that supports Confidential computing, but the main challenge has been how to protect data and code while it is being processed. By comparison, it is relatively easy to protect data at rest and data in motion by using strong encryption, digital signatures, and careful key management.

With the recent publication of the first open-source patches that support the Realm Management Extension (RME), now is a great time to look at the latest developments and features for Confidential computing on Arm. In this blog I, provide a brief overview of the techniques that can be used to build a computing platform that supports Confidential computing. This includes a summary of the newest features Arm has added to the Armv9-A Architecture, and details of Arm’s supporting reference software architecture.

What are the threats that designers consider?

The designers of any platform providing Confidential computing must analyze the threats and risks that need to be defended and those which are acceptable and therefore considered to be out of scope. Example threats that are typically considered in this analysis include:

• Vulnerabilities in platform software that could be exploited.
• The insertion of a known vulnerability (sometimes called a backdoor) in the supply chain.
• Physical attacks against operational servers.
• The leakage of information across security boundaries through side-channels such as the time taken to complete an operation.
• Third-party administrators accessing and misusing sensitive data.
• Concerns over data sovereignty and foreign state access.
• The risk that moving from a private data center to a third-party cloud makes it harder to demonstrate compliance with regulatory standards.

Mitigations

Mitigating these and other threats often requires a fundamental change to the familiar model of computer security that relies on a hierarchy of privilege levels, whereby each level implicitly trusts the more privileged layers of infrastructure here.

Fig. 1: An example of the traditional hierarchy of privilege.

Examples of components that often have the greatest privilege and that must therefore be trusted by end users include platform firmware and where relevant, a virtualization hypervisor. This infrastructure often has unfettered access to workloads and is trusted to not abuse this privilege. This can cause concern if the privileged code is considered likely to contain exploitable security vulnerabilities. Removing or reducing the need to trust this privileged infrastructure, that maybe invisible to users, can be achieved in a variety of different ways, including:

• Rearchitecting the platform to reduce the amount of privileged software and hardware that has access to a workload.

• Protecting everything associated with a workload with encryption as close to the point of processing as possible. For example, encrypting a workload’s code, state, and data in memory.
• Where privileged elements remain, ensuring these are open, available for inspection, and locked down using techniques like secure boot and platform attestation so that they cannot be changed without authorization or detection. Formal methods may be used to provide further assurance that these elements are trustworthy.

Protecting workloads in a virtualized environment

Arm introduced processor support for virtualization, including stage-two translation tables, in the Armv7-A Architecture. These features provide effective hardware-backed address space isolation between virtual machines that share a platform. It is possible to use this and other features of the A-Profile Architecture to build a platform that supports Confidential computing. Where virtualization is used, the hypervisor typically has sufficient privilege to access user workloads, but controls can be put in place to provide assurance that the hypervisor will not abuse that privilege. For example, the risk of a bad hypervisor can be mitigated by making the hypervisor small, open, and verifiable. Formal methods can be used to demonstrate the hypervisor functions correctly and a secure root of trust can then be used to prevent unauthorized changes to the platform and to underpin attestation. The root of trust is typically a dedicated secure microprocessor that controls the boot process by loading and verifying the system firmware before releasing a main system CPU from reset.

Adding a new dimension of hardware-backed security

In 2021, Arm announced the Realm Management Extension (RME) as a major addition to the Armv9-A Architecture, and the Arm Confidential Compute Architecture (Arm CCA). Arm is working with several partners on the first silicon implementations of RME.

RME is an isolation architecture that allows hypervisors to create and manage special execution environments for workloads called Realms. A Realm is a protected environment that is designed to provide additional security to workloads such as virtual machines. When a virtual machine runs within a Realm, a hypervisor has the same powers to create, destroy, schedule, add, or remove resources such memory and devices as they do for traditional virtual machines. The key difference is that a hypervisor cannot access the code or memory of a Realm. In this sense the hypervisor is deprivileged, and a workload can use attestation to verify that this deprivileging has occurred before it loads any sensitive code or data. We expect RME to become a mainstream feature in future generations of CPU. RME provides another tool that can help security architects reduce the amount of code that has access to workloads and can be used to further harden a platform that supports virtualization. RME also standardizes support for memory encryption and attestation.

The 2022 architecture extensions

Arm announces updates to the A-Profile Architecture annually, and in 2022, we announced enhancements to RME to support a wider range of use cases with Memory Encryption Contexts (MEC) and Device Assignment (DA).

• MEC introduces support for multiple memory encryption contexts for the Realm physical address space. This can be used to implement memory encryption with a unique key for each Realm, which provides additional defense-in-depth to the security already afforded by Realms.

• DA enhances the RME System Architecture and SMMUv3 to enable the secure assignment of devices to Realms. Each Realm can independently choose whether to allow an off-processor resource such as a storage interface, or an accelerator, to access a region of its address space. So, with DA a workload can take full advantage of the specialist resources such as neural processors that are available on heterogeneous platforms without compromising security.

The specification for RME incorporating MEC can be found in version J.a of the Arm Architecture Reference Manual and the specification for DA will be published shortly. See https://www.arm.com/armcca for further information.

Reference software architecture

When Arm delivers new architectural features that are implemented in hardware, we also think about what is needed to make use of those features in a complete system. Some partners prefer to take Arm’s hardware architecture and create their own software that is tailored to their specific market and needs, while others appreciate the option of a more complete solution that includes software. For this reason, we created the Arm Confidential Compute Architecture (Arm CCA) that includes RME.

Fig. 2: Arm CCA builds on RME to provide a reference software security architecture. 

Arm CCA builds on RME by providing an optional reference firmware and software security architecture that can be used to implement a hypervisor-based platform that supports Confidential computing. By choosing Arm CCA in addition to RME, Arm’s partners benefit from an established software architecture that supports popular open-source projects including Trusted Firmware-A, Linux, and KVM. Arm CCA is an open architecture that is being actively assessed using formal methods, helping partners to demonstrate that their security technologies follow established best practice. The use of a standard software architecture improves portability, and reduces the burden of long-term maintenance, and can also lead to greater transparency of implementation. You can read more about Arm CCA at developer.arm.com.

I am delighted that Arm has just published the first Arm CCA “Request for Comments” patches for the Linux stack with contributions to the Linux kernel and KVM. Following review, I hope these contributions will be accepted by the upstream projects. This helps a broad range of service providers offer secure Confidential computing on Arm-based systems without the cost and complexity of developing their own custom solutions. You can find the Request for Comments for the Arm CCA Linux stack here. The first EDK2 patches for guest firmware are available.