Confidential Computing Availability

Availability Summary¶

• ✅ full support

• 🟠 partial support

• ❌ no or minimal support

• ❓ unknown

Public Cloud¶

AWS¶

AWS offers a number of infrastructure level security features as part of its Nitro hypervisor. Among these are confidential computing features, including always-on memory encryption. This feature protects users from people with hypervisor or hardware access. It could be considered a TEE if applications were segregated by running on different instance, but this is not scalable solution. To segregate data and software on the same host Nitro enclaves, an AWS in-house enclave TEE implementation, can be used. This extra isolation protects data from the customers own users and software, in addition to the default protection against AWS themselves. Both of these Nitro features are available on AMD, ARM and Intel-based instances.

With compatible AMD instances, users can also opt to enable SEV-SNP. This gives customers more flexibility to take over management of instance-specific encryption keys and attestation. There is an extra charge on top of instance rate for enabling SEV-SNP. Currently no GPU instances support enabling SEV-SNP

Azure¶

Azure offers a number of VM sizes supporting confidential computing, and an attestation service. SGX, TDX and SEV-SNP may be enabled on compatible sizes. The NCCadsH100v5-series size support confidential computing with a GPU, combining an AMD EPYC Genoa CPU with an Nvidia H100 GPU.

SEV-SNP enabled VMs can be included in AKS node pools Confidential VMs can also be used to back some other services like remote desktop and PostgreSQL.

GCP¶

GCP has a variety of confidential computing services. Confidential VMs may be deployed with with Intel or AMD processors using SEV, SEV-SNP or TDX on compatible sizes. One size compatible with confidential computing includes H100 GPUs. Confidential VMs can be used as nodes in GKS Kubernetes.

Challenges in Adoption in HPC¶

The hardware of many modern HPC systems support confidential computing and TEEs. The proportion of compatible clusters will increase as older generations of hardware are decommissioned and replaced. However, even in cases where hardware would allow it, CC and secure virtualisation are not available to users.

Enabling CC presents a number of challenges for the administrators of HPC systems, which prioritise stability^[1], reliability^[2], uptime^[3], performance^[4] and throughput^[5] to maximise their usage and output.

Activating the CPU and secure processor features that enable CC is done through UEFI. In a HPC system these changes must be made on every node that must support confidential computing, potentially hundreds or thousands of nodes. More problematic that UEFI configuration is managing the OS and kernel versions across nodes. This is necessary as TEE implementations will require compatible kernels, and hence OS.

Changing the kernel or OS version on a HPC system risks introducing bugs or breaking existing hardware. HPC systems tends to lean towards LTS^[6] kernels for stability, which may lack support for the CC features of new hardware. For example, at the time of writing, Rocky Linux 9 and RHEL 9 (popular choices for HPC) by contrast, operate on Linux kernel 5.14, which does not support CC. The latest release, RHEL 10 (updated to kernel 6.12) offers support for CVMs as a technology preview. Technology preview features are not fully supported and are intended for production use. So, with the latest RHEL release operators would take on risk in using a feature that is not fully supported and without guarantee.

Furthermore, HPC systems may rely on drivers for high performance hardware (parallel storage, fast networking, accelerators) which impose restrictions on kernel versions. It is therefore possible that administrators must choose between CC support or hardware features when deciding on a kernel version. In these cases the optimal functioning of hardware is likely to win out over a relatively niche feature.

Both UEFI and kernel/OS configuration steps would require downtime to implement on an existing system. Kernel/OS changes in particular could result in extended downtime as it may additionally require rebuilding software, updating drivers, or rewriting scripts in reaction to CLI changes.

The data protection afforded by TEEs comes with a negative impact on performance. Performance loss typically varies between 2% and 10% compared to conventional VMs. The performance difference depends strongly on the workflow, with memory-intensive work suffering higher losses than CPU-bound tasks Liu et al., 2025Coppolino et al., 2025. The performance gap between confidential and conventional workloads will likely decrease as TEEs are further developred. However, the performance loss and increased memory latency will likely prevent it being used by default. For users the performance cost may be an acceptable to enabled trusted research on an HPC system. However, for HPC operators a significant number of confidential jobs would reduce the throughput of the cluster compared to only non-confidential processes.

Additionally, many HPC systems do not support virtualisation at all. For most jobs, creating a virtualmachine would be unnecessary and only result in longer stand-up and run times. Even when it is, the scheduling of CVMs is also a challenge. A simple way to handle this would be to create persistent CVMs, which are handed over to users, who then manage attestation and work interactively in the TEE. However, this will lead to the allocated resources spending much of their time idle and unavailable to other HPC users. Alternatively, CVMs could be created dynamically by the scheduler in response to demand, but that presents new challenges in building infrastructure to manage the secure release of confidential data, the workloads and secrets to the CVM. This is similar to the set of challenges the Confidential Containers project addresses for Kuberentes.

Conclusion¶

As it stands, there is a little support for confidential computing in UK national-scale research computing. The first generation of AIRR supercomputers, Dawn and Isambard-AI, both lack hardware supporting TEEs. A number of Tier 2 systems have hardware compatible with secure virtualisation. However, none offer CC to users. Significant challenges remain in how to support CC in the HPC context. As the adoption of TEEs increases, this may leave a gap in the ability to conduct research using sensitive data, particularly for AI tasks.

Currently, cloud providers fill that gap, with the largest services offering a choice of TEE implementations and hardware configurations (including GPUs). These resources may not be available to all research, for example when data governance imposes restrictions on the geography of data storage. It also presents a presents challenges for researchers in managing costs and avoiding dependence on large-scale, private compute providers. Better support from national resources could help enable research, promote the safe use of sensitive data in research and make research more financially efficient.

If there is critical need for CC on the next generation of HPC machines, it must be influence the design of the system from conception. Beginning at procurement, hardware that supports CC must be chosen. CC support must also factor into kernel and OS choice, alongside constraints from other hardware and considerations of stability and software support. Beyond that, there is a significant unsolved problem of how to schedule and manage TEEs in a manner suitable for HPC. At present, with the lack of an open project similar to Confidential Containers for HPC, early adopters may find they have to implement this supporting infrastructure themselves.