Workloads Keeping Secrets: Confidential Computing

(Day 19 of 22 in our Cybersecurity Awareness Month series. Today: confidential computing)

Data has three states. It’s at rest when it’s stored, in transit when it’s moving across a network, and in use when it’s being processed. Other posts in this series cover the first two, with storage encryption and network encryption. The third has always been the hard one, because to do anything with data, the processor has to see it, and anything that controls the processor, like an operating system or a hypervisor, can see it, too.

Confidential computing changes that. It uses features built into modern AMD and Intel processors to keep a virtual machine’s memory encrypted and isolated from everything outside the VM, including the hypervisor and the people who run it, and VMware Cloud Foundation (VCF) supports confidential VMs on both.

What Confidential Computing Protects Against

The Confidential Computing Consortium defines confidential computing as “the protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment” (CCC). In practice, the processor manages a separate key for each confidential VM and encrypts the VM’s memory with it. The hypervisor doesn’t hold those keys, so even someone with administrative access to an ESX host can’t use the hypervisor to read a confidential VM’s memory in cleartext (confidential computing in VCF).

That matters because whoever controls a hypervisor can normally see everything inside the VMs it runs. A memory snapshot, like the ones in our post on snapshots, captures the passwords, keys, and data of a running VM. That’s useful to incident responders, and just as useful to an attacker who has gained administrative access. Attackers can also arrive from below: one exploited chain of vulnerabilities let someone with administrative access inside a guest escape to the host, where the memory of every other VM would normally be within reach.

Confidential computing largely takes memory off the table for those attackers. It’s a good fit for workloads like key management systems, secure databases, regulated workloads, and private AI, where the data in memory is the most valuable thing on the system.

How Confidential VMs Work

VCF supports one processor technology from each vendor:

• AMD SEV-SNP (Secure Encrypted Virtualization with Secure Nested Paging), on AMD EPYC processors from the Milan generation onward. It encrypts VM memory and adds integrity protection that keeps the hypervisor from replaying or remapping a VM’s memory (AMD).
• Intel TDX (Trust Domain Extensions), on 5th Gen Intel Xeon processors and later. It runs each confidential VM in a hardware-isolated trust domain, protecting the confidentiality and integrity of its memory and CPU state (Intel).

Hosts that run confidential VMs can use Quick Boot, too. Setup has three parts: turn on the processor features in each server’s firmware, use virtual hardware version 22 or later, and choose the confidential VM mode under VM Options > Confidential Compute while the VM is powered off (SEV-SNP, TDX). Confidential VMs run Linux guests with recent kernels, and Broadcom lists the validated guest operating systems in KB 401005.

VCF Operations shows which hosts support confidential VMs, whether the feature is turned on, and which VMs are confidential. The VCF Security and Compliance Guidelines repository has a detailed set of questions and answers about confidential computing in VCF, and the VMware Cloud Foundation YouTube channel has a video on it, too:

Attestation: Proving It’s Real

Encrypting memory is only half of confidential computing. The other half is attestation, which lets a workload, or the people who own it, verify that it’s running in a genuine, correctly configured trusted execution environment before trusting it with secrets. NIST describes attestation as verifiable cryptographic evidence that lets a relying party send secrets directly into the protected environment (NIST IR 8320).

The processor signs a report describing the confidential VM, and a verifier checks that report against the processor vendor’s certificates (details):

• AMD SEV-SNP guests generate an attestation report from inside the guest and verify it against AMD’s published certificates using open source tools. SEV-SNP can also check a VM’s expected measurements before it’s allowed to start.
• Intel TDX guests generate a signed quote through the Linux kernel, using an attestation component installed on each host, and the quote is verified using Intel’s services.

The evidence goes to whatever verifier you choose, often a key management or secrets system that releases keys only to VMs that pass. Design that flow up front, because attestation only helps when something acts on the result.

What Confidential VMs Don’t Protect Against

Confidential computing is a strong control with a specific scope. It doesn’t protect against:

• Problems inside the guest. A vulnerable application, a weak password, or malware running in the VM sees the same cleartext memory the workload does. The guest still needs patching and hardening, and it should treat anything coming from the host as untrusted (Linux kernel threat model).
• Data on disk. Confidential computing covers data in use. Attackers who reach vCenter have cloned sensitive VMs, like domain controllers, and read their disks offline (report), and memory encryption doesn’t stop that. Encrypt a confidential VM’s disks from inside the guest, ideally with keys that are released only after a successful attestation.
• Denial of service. The hypervisor still decides when a VM runs and what resources it gets, so someone who controls a host can still stop a confidential VM.
• Sophisticated physical attacks. The consortium’s definition puts these out of scope, and researchers have shown attacks that use tampered memory modules to undermine these protections, which processor makers have addressed with firmware updates (example). Keep server firmware current, and keep physical security in place.

Operational Trade-Offs to Plan For

Confidential VMs give up some of the conveniences that make virtualization pleasant, because many of those conveniences depend on the hypervisor being able to see or copy a VM’s memory. Confidential VMs don’t support:

• vMotion, so plan maintenance around powering VMs off, or around failover at the application level.
• Memory snapshots, memory tiering, or suspend and resume.
• Fault Tolerance, or hot-adding CPU and memory.
• A virtual TPM or Secure Boot inside the guest, so the advice in our post on VM security features doesn’t fully carry over.
• VMware Tools inside Intel TDX guests.

A few more things to plan for:

• Linux guests only. The validated guest list is specific, but industry support is growing (KB 401005).
• Memory is fully reserved. All of a confidential VM’s memory is reserved on the host, and hosts using Intel TDX also set aside memory for the processor’s security features, so capacity planning changes.
• Attestation needs a path. Intel TDX attestation relies on Intel’s remote provisioning and verification services, so isolated environments need a plan for reaching them.
• Firmware settings matter. The processor features have to be turned on in each server’s firmware, consistently across the cluster, and the VCF Security Configuration Guide includes controls for it.

Where Confidential Computing Fits

Not every VM needs confidential computing. Most workloads are well served by the features in our post on VM security, along with storage encryption and good access control. Confidential computing earns its trade-offs for workloads where the data in memory is the crown jewels, like key management systems, secrets vaults, sensitive databases, regulated workloads, and private AI models and the data they process.

Start small. Pick one workload, check that your servers and guest operating systems are on the supported lists, work out how attestation will control the release of secrets, and plan around the operational trade-offs. Use VCF Operations to keep track of which hosts are ready and which VMs are confidential.

Every workload trusts the infrastructure it runs on. With confidential computing, it can trust a little less.