Confidential Computing Support

Current State of Confidential Computing¶

Confidential computing technology is still in a state of rapid development and prone to flux. For example, AMD SEV technology has had a number of extensions including SNP, which includes important security improvements which could be considered essential for a TEE. However, it has reached a state of maturity where the latest few generations of CPUs have support for robust and competent TREs. This is mostly reserved for data-centre hardware, and not yet available on consumer devices.

Support utilising GPUs in TEEs is emerging, but less well developed that for CPUs. Nvidia is currently the only vendor to offer GPU support in a TEE, and that is restricted to the lasted generation of Hopper devices. This is discussed in GPU

TEE Archectypes¶

Two key archetypes for TEEs have emerged.

Secure VMs¶

VM-based TEEs are the most common approach, and appear to currently have the most focus from hardware manufacturers. Examples include, SEV-SNP, CCA, and TDX. They work by provisioning secure virtual machines on a hardened hypervisor. The guest is secured through the encryption of all its memory using a key unique to that guest. Therefore, if another process is able to read those memory addresses, they can only see the encrypted data. A secure VM TEE implementation may further protect and isolate pages belonging to a TEE from inspection in more sophisticated attacks, for example those targeting the hypervisor, exploiting out of date firmware, or requiring physical access.

The segregation of the secure guest from the host means that there is no need to trust the host OS and any software on the host. The guest OS must be trusted and forms part of the TCB. The root of trust remains the host CPU and hardware vendor. An example block diagram showing the trusted and untrusted components of a VM-based TEE is shown in Figure 1. In contrast to the previous, similar example the guest OS is now a trusted component.

A secure VM TEE may provision a lower-trust portion of memory, which allows the transfer of data between the host and guest.

An advantage of the VM-based TEEs is their flexibility. Little or no code changes will be required for software to run in such a TEE. Building a secure application does not involve using confidential computing APIs (possibly with the exception of moving data between host and guest) a confidentiality is guaranteed by the hardware and VM.

Enclaves¶

Unlike VM-based TEEs, enclave TEEs run directly on the host. Also in contrast, the OS running the trusted workload (in this case the host OS) is not trusted. This is achieved by creating a secure enclave, a cryptographically segregated portion of the CPU and memory, where the trusted routines runs, before returning the result. Only the functions which must be secure need to be run in the enclave. Any other application code can run outside of the enclave.

The basic workflow for an enclave TEE is,

1. Untrusted code requests an enclave

2. Trusted hardware creates enclave

3. Untrusted code triggers attestation of enclave

4. Untrusted code decides whether to proceed

5. Untrusted code calls trusted routine

6. Trusted routine runs and returns result

7. Untrusted code processes result

Figure 2 is a block diagram showing the trusted and untrusted components of an enclave TEE.

Enclave TEEs have a smaller TCB compared to VM-based TEEs as there is no guest OS, and only a small part of any application needs to be trusted. This would make an in-depth security audit more feasible. Developing for an enclave TEE will require calling CC APIs. Translating an existing application would require splitting trusted routines and adding steps to create, attest and use enclaves to the untrusted part.

Confidential Containers¶

A more recent and promising approach to confidential computing is confidential containers The Confidential Computing Consortium, 2022. These are processes from OCI container images, launched by a container runtime, running in a TEE. That way, the container process is protecting from the host.

Confidential Containers is a project of the CNCF building open source tools to support running container applications in TEEs. The project extends Kata, a container runtime which runs container processes in lightweight virtual machines, rather than conventional sandboxes using Linux namespaces and cgroups. Confidential Containers builds on Kata by ensuring images and workload data are pulled by the confidential guest (not the host), handling attestation, and managing secure communication between the guest and external, trusted resources. There is existing support for a number of different TEE implementations and archetypes. In addition to the container runtime, Confidential Containers maintains a set of trusted components to manage the lifecycle of ephemeral TEEs, including attestation and secret management. These components run off of the confidential guest and are collectively called Trustee.

Confidential Containers uses one TEE per pod. This decision was made as a compromise between security and convenience. The TCB is larger than if each container were run in its own TEE, but avoids the complex configuration required for containers in the same pod to share data. An alternative approach, would be to build a Kubernetes cluster from CVM nodes. This would be simpler to implement, however it greatly increases the size of the TCB as now all processes running on the kubernetes nodes, such as Kubelet and potentially etcd, would be within the TEE.

Each pod is therefore crytographically isolated from both the host and other pods in the K8s cluster. Altogether, Confidential Containers represents a level 3 confidential computing implementation The Confidential Computing Consortium, 2026 where attestation happens at a workload level and considers measurements of that workload. The confidential guest is a minimal image only capable of producing measurements and executing approved processes.

Confidential Containers additionally provides features to manage and interact with confidential containers. These include being able to query attestation evidence in container processes, directing the confidential guests to pull from container image proxies, and providing container processes with access to encrypted secrets. These tools can be used to build more complex workflows than simply running discrete confidential pods.

GPUs and other devices¶

TEEs are CPU-based, with the important processes maintaining confidentiality and creating trust being handled by the secure processor. There is therefore a challenge integrating devices, such as GPUs, with TEEs as there needs to be a mechanism for confidential data to be moved from the TEE to a trusted device without exposing it in plain text on the host. Some TEE implementations allow for the creation of shared memory Kaplan et al., 2021. These are pages which can be accessed by both the host and TEE, and are not encrypted by the TEEs memory encryption key. This space can therefore be used to send messages between the host and TEE.

To communicate with a trusted device, shared pages can be used as a bounce buffer. Instructions from the TEE can be encrypted using a device public key and written to the shared memory, where the device can read before decrypting in it’s own confidential computing zone. This way, the communication between device and TEE are never exposed to the host in plain text.

An alternative approach is to allow DMA to the TEE from the device. This approach is more performant as data does not need to pass through an intermediate buffer, reducing latency. It is also potentially more secure as messages between TEE and device are never stored in memory pages available to the host OS or hypervisor. However, to use a device in this way both the device and CPU must support a common method for this communication. The PCI-SIG has produced two specifications for this purpose,

• IDE provides a method to encrypt communication between TEE and devices over PCIe.

• The TDISP protocol can be used to establish trust with, connect, and disconnect a device to a CVM.

As with the CPU, it is important to establish trust in devices connected to a TEE. Before trust in a device has been established, a TEE should not use it. With an untrusted connection established (either through a bounce buffer or TDISP), evidence gathering similar to with a CPU can occur and claimed verified in an attestation report.

Vendor Support¶

AMD¶

CPU¶

Summary¶

SEV-SNP is AMD’s TEE implementation. It is a secure VM TEE. SEV was the original secure virtualisation implementation. There have been a number of additions to these original features and support varies across CPU generations. In particular, SNP adds important memory protections for hypervisor-based attacks. SEV is a TEE, but care should be taken as without SEV-SNP, there are known vulnerabilities which could be exploited by those with access to the hypervisor or host system.

Communication between host and secure guests is supported in SEV. Each guest is able to specify which pages of memory should be private (encrypted with the guest’s unique key) and shared (encrypted with a hypervisor key).

Communication with devices using TDISP/IDE has been supported since 9005 (Turin) in a feature called Trusted IO.

Hardware Support¶

TEEs are a feature of the datacentre EPYC line of CPUs. SEV is supported from EPYC 7001 (Naples) and SEV-SNP from 7003 (Milan). The AMD website has a table of features introduced across subsequent CPU generations.

GPU¶

The MI455X will be the first AMD GPU to support TEE integration. Connection will be made through TDISP/IDE and compatible with Intel and AMD CPUs which also support those standards. The Helios system will incorporate MI455Xs, Pensando NICs and AMD Venice CPUs. Both the NICs and GPUs can be passed to CVMs.

Resources¶

• AMD Infinity Guard security technologies

• AMD SEV developer information

• AMD confidential computing

• SEV-SNP whitepaper

• SEV-SNP attestation process presentation at Linux Security Summit 2022

• Trusted I/O whitepaper

ARM¶

CPU¶

Summary¶

CCA is ARMs TEE implementation. It is a secure VM approach, which depends on the strongly related RME technology, for managing isolated VMs (termed realms) on ARM platforms. CCA is less mature than SEV-SNP and TDX. It is available on ARM datacentre CPUs but there is also an emphasis on making TEEs available on ARM-based mobile, automotive and embedded devices.

Hardware Support¶

CCA was introduced in with the RME instructions ARMv9-A in 2021. The instructions may optionally be implemented on ARMv9-A CPUs A number of Cotrex mobile and Neoverse datacentre CPUs have been developed with this or later, architectures. The Neoverse V3 datacentre/cloud processors support CCA. These have been manufactured into SoCs, AWS Graviton5, Azure Cobalt 200 and Nvidia Thor.

Resources¶

• ARM CCA feature summary

• CCA on Fujitsu Monaka upcoming CPU blog post

• RME developer guide

Intel¶

CPU¶

Summary¶

Intel has two TEE implementations, SGX and TDX TEE technology on Intel CPUs is implemented as part of the IME. This, is an off-CPU subsystem built into the chipsets of Intel motherboards.

The older of the two implementations is SGX. Intel SGX is an enclave and hence allows TEEs to run directly on a compatible host system. SGX also refers to the instruction set extension for x86 that implement the TEE. As developing for enclave TEEs requires significant code changes, Intel produces an SDK for SGX applications.

Intel TDX is a newer system for confidential computing than SGX. Unlike SGX, TDX is a secure VM TEE. The confidential VMs are referred to as trust domains. Communication between the host and TEE is possible through a shared portion of memory, the Shared Extended Page Table.

TDX TEEs support integrating devices through TDISP/IDE in a feature called TDX Connect

Hardware Support¶

SGX was previously available on both consumer and datacentre processors, with support going back to the Skylake family in 2015. Support has been removed in recent consumer devices, as Intel focuses more on developing TDX. Support has remained for the latest generations of Xeron processors, with Intel indicating that they are committed to continued support on Xeon.

TDX is supported on the 5th and 6th Generation Xeon (Emerald Rapids and Granite Rapids respectively) CPUs. Some cloud providers have special SKUs of 4th Generation Xeon (Sapphire Rapids) which are TDX-compatible, however these are not generally available.

Resources¶

• SGX

• SGX Developers Guide

• Intel SGX Use and Development Flow

• TDX

• Which Intel TEE is right for you graphic

• Intel Trust Authority attestation service

• TDX Connect specification

GPU¶

Intel GPUs currently have no support for TEEs.

Nvidia¶

GPU¶

Summary¶

For its recent GPU architectures, Nvidia has developed technology to allow its accelerators to be attested and used in secure guests Nertney & Mandakolathur, 2025. Integration of Nvidia GPUs is supported for SEV-SNP, and TDX.

Hardware Support¶

Confidential computing is supported on the Hopper, Blackwell and Rubin architectures of datacentre GPUs. When provisioned on a TEE capable host from a compatible vendor, a GPU from these families may be used by a CVM. Bounce buffers can be used with all families but DMA with TDISP/IDE is only supported from Blackwell onwards Nertney & Mandakolathur, 2025. Single, or multiple GPUs can be connected to a CVM, however, with Hopper this is limited to specific HGX products.

The announced Vera Rubin superchip will support confidential computing. It is comprised of Rubin GPUs and Vera CPUs (with custom ARMv9-A cores) on a tightly integrated datacentre rack.

Resources¶

• Nvidia confidential computing

• H100 confidential computing blog post

• Vera Rubin blog post