↓ Skip to main content
Le Site de François
  1. Index/

Confidential VM (CVM)

Security Confidential-Computing Virtualization Tee Cloud
Table of Contents

A Confidential VM (CVM) is a virtual machine in which the guest’s memory contents, CPU register state, and execution flow are hardware-encrypted and isolated from everything outside it: the hypervisor, the host operating system, the cloud operator, other tenants, and anyone with physical access to the machine. The isolation is enforced not by software policy but by the CPU itself, using TEE technology — Intel TDX, AMD SEV-SNP, or Arm CCA — so that no amount of privilege on the host side grants access to the guest’s private state. A CVM is the VM-granularity equivalent of what SGX enclaves provide at the process level: the key difference is that a CVM requires no application changes, making it the practical path for lifting existing workloads into a confidential computing environment.

The security properties of a CVM vary by underlying technology but share a common structure. Memory is encrypted with a per-VM key held inside the CPU or on-die security processor, so DRAM contents observed by the host (through DMA, memory probing, or cold-boot attack) are ciphertext. CPU register state on VM exit is either encrypted (SEV-ES and later) or mediated through a trusted module (TDX’s SEAM mode) so the hypervisor cannot read or inject guest execution state. Memory integrity protection (SEV-SNP’s Secure Nested Paging, TDX’s memory tagging) prevents the host from replaying, remapping, or aliasing guest memory pages without the guest detecting it. Together these properties enforce the defining guarantee of a CVM: the guest’s confidentiality and integrity hold even against a fully compromised hypervisor. What they do not protect against is a compromised guest OS or application — once an attacker has root inside the CVM, the TEE boundary does not save it. The threat model is the infrastructure, not the workload itself.

The other defining property of a CVM is attestability: the TEE hardware can produce a signed report — a TDX Quote or SEV-SNP attestation report — that cryptographically binds the CVM’s identity (its measured firmware, kernel, and initial state) to a hardware-rooted key that only genuine, unmodified hardware can produce. This report is what allows a workload owner to verify, from outside the cloud, that their CVM is running on real confidential hardware with an unmodified software stack before sending it secrets. CVMs are the runtime substrate for CoCo (Confidential Containers), where each pod runs inside a CVM; for Confidential Clusters, where every Kubernetes node is a CVM; and for Trustee, which releases secrets only to CVMs that present a valid attestation report.

Relevant Red Hat blog posts
#

Related

Confidential Cluster

Security Confidential-Computing Kubernetes Attestation Tee
A Confidential Cluster is a Kubernetes cluster designed so that the cloud or infrastructure operator — including hypervisor administrators, datacenter staff, and anyone who can access the underlying hardware — is entirely outside the trusted computing base. It achieves this by running every Kubernetes node, including control plane nodes, as a Confidential VM, and by extending the confidential boundary to cover not just individual workloads but the cluster’s network traffic, persistent storage, and control plane state. The goal is that a workload owner can cryptographically verify the entire cluster before trusting it, and that no privileged party outside the cluster’s own CVMs can read or tamper with workload data, cluster secrets, or etcd contents.

SEV-SNP (AMD Secure Encrypted Virtualization – Secure Nested Paging)

Security Confidential-Computing Hardware Attestation Virtualization Amd
SEV-SNP is AMD’s third-generation confidential computing technology for EPYC processors, and the generation in production use across major cloud providers (AWS, Google Cloud) and Linux distributions today. It builds on two predecessors: SEV (2016), which encrypted each VM’s memory with a per-VM AES key managed by the AMD Secure Processor, and SEV-ES (2017), which additionally encrypted CPU register state on VM exit to prevent the hypervisor from reading guest execution state. SEV-SNP’s defining addition is memory integrity: using Secure Nested Paging, the firmware enforces that if a guest can read an encrypted memory location, the value returned must be exactly what the guest last wrote there — closing the replay, remap, and memory aliasing attacks that made earlier generations insufficient for a fully untrusted hypervisor threat model.

TCB (Trusted Computing Base)

Security Confidential-Computing Virtualization Attestation Linux
The Trusted Computing Base (TCB) is everything you must trust for your security guarantees to hold: CPU and firmware, the host kernel, the hypervisor, the container runtime, the kubelet, identity and secrets infrastructure, and any management plane that can change workload configuration. If any component in the TCB is buggy, misconfigured, or controlled by an adversary, the whole security argument fails — regardless of how well the application itself is written. The classic design principle is TCB minimisation: keep this set as small as possible, because every added component is another place where a flaw can void your policy. “Trusted” here does not mean “trustworthy in practice”; it means “assumed correct by the security model.”