Confidential Virtual Machine (CVM)

A Confidential Virtual Machine (CVM) is a virtual machine that runs inside a hardware Trusted Execution Environment (TEE), protecting the guest’s memory and execution from inspection or tampering by the hypervisor, host OS, and other privileged software.

CVMs impose the least restrictions of any CC deployment model: existing applications run unmodified inside a CVM, with no code changes required.

References: Red Hat — Introduction to Confidential Virtual Machines, Edgeless Systems — CVMs

CVM Threat Model¶

The untrusted components include the host OS, KVM hypervisor, other VMs on the same host, other processes on the host machine.

Application code vulnerabilities, availability attacks, and software TEEs are out of scope.

What a CVM Protects¶

CVMs provide workload confidentiality. The data in use is isolated from higher-privilege layers:

What CVMs Do NOT Protect Against¶

• Vulnerabilities within the guest workload (application bugs, remote exploits)

• Availability attacks (DoS)

• Attacks that originate inside the guest with legitimate access

Memory Encryption¶

The hardware memory controller transparently encrypts all guest physical memory pages with a key held inside the CPU. The hypervisor sees only ciphertext when it accesses guest memory.

AMD SEV-SNP uses a dedicated processor called AMD Secure Processor (ASP), also known as AMD Platform Security Processor or PSP, to manage its security features. ASP is an ARM-based processor separated from the main x86 cores but directly integrated into the CPU die, creating a hardware root-of-trust. The ASP securely manages SEV-SNP VM encryption keys and the reverse map table to ensure the integrity of the guest address translation.

Intel introduces two new components: a new CPU operation mode Secure Arbitration Mode (SEAM), and special trusted software the TDX module. A Trust Domain (TD) is a virtual machine that runs in a secure environment under the control of the TDX module.

Data at rest in a CVM also requires protection — the host controls storage access, so full disk encryption (e.g., LUKS) is mandatory for any sensitive data persisted to disk.

Boot Chain Security¶

A critical risk in CVMs: even with memory encryption, a malicious host could swap binaries before they are loaded into protected memory. Every executable must therefore be authenticated before execution.

UEFI Secure Boot¶

Secure Boot ensures only vendor-signed code executes during boot:

Unified Kernel Image (UKI)¶

A UKI bundles the kernel, initramfs, and kernel command line into one signed UEFI binary, extending trust to components that were previously unsigned:

Trade-offs: the initramfs and kernel command line are fixed at build time — they cannot be modified dynamically (e.g., root= cannot be set at runtime).

Measured Boot and the Root Volume Key¶

Even with Secure Boot, a signed kernel could be paired with a crafted initramfs to extract a volume decryption key. The solution is PCR-gated key unsealing:

1. Each boot component extends a PCR register: PCR_new = SHA256(PCR_old || component_hash)

2. The volume decryption key is sealed to a TPM policy requiring specific PCR values

3. The hardware evaluates the policy — if any boot component changed, PCRs differ and the key is not released

4. A compromised guest OS cannot circumvent this because the hardware enforces it

Key PCRs for CVMs:

The vTPM Role¶

A virtual TPM backed by hardware (rather than managed by the hypervisor) enables:

• Automated (unattended) key unsealing — no user password at boot (which the host could intercept via console emulation)

• Attestable genuineness — under SEV-SNP or TDX, a vTPM inside the TEE cannot be faked by the host

• PCR-based policies — the same policy model used for bare-metal TPMs works inside the CVM

When the vTPM is placed inside the TEE (via SVSM on AMD SEV-SNP, or natively on Azure CVMs), the hypervisor is completely excluded from the trust chain.

Remote Attestation for CVMs¶

The hardware generates a signed attestation report containing the boot measurements. A remote party can use this to verify:

1. The VM is genuinely running inside a hardware TEE (not a software simulation)

2. The correct guest OS was booted (measurements match expected values)

3. The hardware is at the required firmware/patch level

Hardware Technologies¶

All major CPU vendors support CVMs.

Cloud Availability¶

Performance and Operational Considerations¶

A common first question: what does the encryption cost? The honest answer is “usually little, but it depends on the workload”, and the overhead is rarely where people expect it. Published measurements cluster around 5% overall: across nearly 200 benchmarks on Azure EPYC 9005 confidential VMs, Phoronix measured SEV-SNP guests at 95% of the performance of regular VMs, and Intel’s own testing of TDX on 4th Gen Xeon concludes roughly 5% for CPU- and memory-intensive workloads.

Runtime overhead¶

• CPU- and memory-bound workloads typically see low single-digit percentage overhead, attributable to memory encryption (performed by dedicated hardware in the memory controller) plus the costlier guest transitions described below. Intel measured about 3% on SPECrate 2017 and up to 4.5% on the memory-latency-sensitive SPECjbb under TDX, and AMD’s SEV-SNP testing on Google Cloud N2D instances showed FFmpeg video encoding performing on par with standard VMs.

• I/O-heavy workloads pay more. Devices cannot DMA directly into the guest’s private (encrypted) memory, so every network packet and disk block crosses the boundary through bounce buffers (shared, unencrypted pages managed via swiotlb in Linux). Each transfer adds a memory copy between shared and private memory, extra guest transitions, and CPU cost per I/O operation. Representative numbers: AMD measured roughly 8% on MySQL and 7% on NGINX for SEV-SNP on Google Cloud N2D instances; Phoronix found 10 to 15% for database and web server workloads on Azure EPYC 9005 CVMs; and Intel measured anywhere from 3.6% to 25% on Redis under TDX, depending on the read/write mix and whether the guest vCPUs had spare headroom to absorb the extra work.

• VM exits are more expensive. On TDX, every guest entry and exit passes through the TDX module (via the SEAMCALL and SEAMRET instructions), which saves and scrubs the TD’s CPU state; on SEV-SNP, register state is encrypted on exit. Both make each transition costlier than a plain VM exit, so exit-heavy workloads (frequent interrupts, timer-heavy applications) are disproportionately affected. Guest tunings such as reducing timer tick frequency or using polling-mode I/O threads reduce the transition rate.

Always benchmark your workload; published numbers vary widely with kernel version, I/O pattern, and hardware generation, and the worst numbers above come from deliberately unfavorable configurations (saturated vCPUs, undersized database buffers).

References: Performance Considerations of Intel TDX on 4th Gen Xeon (Intel), Confidential Computing Performance with AMD SEV-SNP on Google Cloud N2D (AMD), AMD EPYC 9005 SEV-SNP benchmarks (Phoronix), Evaluating Intel TDX for Production Workloads (OpenMetal)

Boot and startup latency¶

• Guest memory must be validated/accepted before use. Large-memory CVMs use lazy memory acceptance to avoid multi-second boot delays; fully pre-accepting memory at launch is slower but avoids runtime acceptance hiccups.

• Attestation adds a network round-trip (to a verifier and/or certificate service) before secrets are released, and quote generation alone takes tens to hundreds of milliseconds. This is a one-time cost for long-running services but adds up for short-lived or frequently scaled workloads; plan for it in autoscaling paths.

Operational restrictions¶

• Memory cannot be overcommitted or swapped by the host: guest memory is pinned. Capacity planning is stricter than for regular VMs.

• Live migration is limited or unavailable depending on the platform and cloud, so host maintenance may mean a stop/restart instead of a transparent migration.

• Snapshots and hibernation of guest state are generally unsupported: this is by design, since exporting encrypted guest state would undermine the threat model.

CVMs as the Foundation for CoCo¶

CVMs are Pillar 1 of the Confidential Computing stack. The CNCF Confidential Containers (CoCo) project builds directly on CVMs:

• Each Kubernetes Pod runs inside its own CVM

• The CVM provides the hardware TEE boundary

• Attestation of the CVM is the root of trust for all CoCo secrets

The chapters that follow cover how CoCo build on this foundation.