Confidential Virtual Machine

The foundational capability of a CVM is the transparent encryption of all VM memory by a dedicated hardware engine integrated into the memory controller. This process uses a VM-specific ephemeral key generated by the processor, which is never exposed to the hypervisor, host OS, or even the cloud provider's administrators. Technologies like AMD SEV and Intel TDX perform this encryption inline as data moves between the CPU cache and DRAM, rendering physical memory access, cold boot attacks, and hypervisor memory introspection futile.

Before a CVM is trusted with sensitive data, its identity and integrity must be verified through a process called remote attestation. The TEE-hardware generates a cryptographically signed report containing a measurement of the VM's initial memory state, firmware, and operating system kernel. This report is sent to a trusted attestation service, which validates the signature against the hardware manufacturer's certificate chain. This proves to a remote relying party that the VM is running the expected software stack on genuine, secure hardware.

In a traditional virtualized environment, the hypervisor has full visibility and control over all VM memory. A CVM fundamentally breaks this assumption. The hardware enforces a strict isolation boundary where the hypervisor is relegated to managing only CPU scheduling and I/O resources, but is cryptographically denied access to the VM's plaintext memory. This protects against a compromised or malicious hypervisor—a critical threat vector in multi-tenant cloud environments.

CVMs support the ability to be moved between physical hosts without exposing data in transit. During a live migration, the VM's memory pages are encrypted using a transport session key negotiated between the source and target TEEs after mutual attestation. This ensures that even if the network link is compromised, the migrating workload's state remains confidential and integrity-protected until it is securely re-instantiated within the new enclave on the destination host.

CVMs are the primary vehicle for deploying Confidential AI, where proprietary models and sensitive inference data are protected during computation. Key use cases include:

• Multi-party model training: Aggregating sensitive datasets from multiple organizations without any party exposing raw data.
• Private inference: Processing user queries against a proprietary model where neither the model owner sees the query nor the user sees the model weights.
• IP protection: Deploying a model to an untrusted edge location while preventing extraction of its architecture and parameters.

A core security principle of CVMs is minimizing the Trusted Computing Base (TCB)—the set of all components that must be trusted for the system to be secure. By removing the hypervisor, host OS, and cloud management stack from the TCB, the attack surface is dramatically reduced. The TCB is limited to the VM's own kernel, the hardware TEE firmware, and the processor itself, creating a verifiably minimal and auditable security boundary.

The mechanism that binds encrypted data to a specific CVM's identity, ensuring it can only be decrypted by the exact same enclave on the exact same hardware.

• Prevents an attacker from moving a disk image to another machine and decrypting it.
• The seal key is derived from the CPU's fused secret and the enclave's measurement.
• Essential for persisting encrypted state across CVM reboots.

The set of all hardware, firmware, and software components that are critical to the CVM's security. A single vulnerability in the TCB can compromise the entire isolation guarantee.

• In a CVM, the TCB includes the CPU microcode, TEE firmware, and the guest kernel.
• The hypervisor and host OS are explicitly excluded from the TCB.
• Minimizing the TCB is a core design goal to reduce the attack surface.