Confidential VM (CVM)

A CVM's memory and vCPU state are encrypted with a key unique to the VM and generated by the hardware. This key is never accessible to the hypervisor or other VMs on the same physical host. This protects against:

• Cold boot attacks on physical memory.
• Hypervisor introspection or malicious administrators.
• Adjacent VM attacks attempting to read memory via DMA (Direct Memory Access). Technologies like AMD SEV and Intel TDX implement this using an on-chip memory controller.

The hardware provides a cryptographic measurement (hash) of the CVM's initial state, including its firmware, bootloader, and kernel. This measurement is signed by a hardware-rooted key. Through Remote Attestation, a remote client can verify:

• The CVM is running on genuine, certified hardware with the correct security features enabled.
• The initial software load is exactly the expected, unaltered version.
• No unauthorized code has been injected prior to launch. This establishes a chain of trust from the silicon to the application.

The hypervisor is removed from the Trusted Computing Base (TCB) for VM confidentiality. While it retains control for resource scheduling and device emulation, it cannot:

• Read or modify the encrypted VM memory contents.
• Inject code into the protected VM.
• Access the VM's CPU register state during execution. This architectural shift is fundamental, transforming the hypervisor from a privileged controller to a distrusted manager of physical resources, drastically reducing the attack surface.

CVMs extend protection to data during processing (data-in-use). For I/O operations, data must be decrypted for the CPU to process it, but this only happens within the secure CPU package. Technologies address the challenge of secure data ingress/egress:

• Encrypted virtual disks: Data is encrypted with VM-specific keys before leaving the CVM's memory space for persistent storage.
• Attested TLS: The CVM can prove its identity (via attestation) to external services to establish secure channels, ensuring data is only released to a verified, trusted environment.

A key security goal is minimizing the Trusted Computing Base—the set of software/hardware that must be trusted for the system to be secure. In a traditional VM, the TCB includes the entire hypervisor and host OS (millions of lines of code). In a CVM, the TCB is reduced to:

• The CPU's secure silicon and firmware (microcode).
• The much smaller, auditable code running inside the CVM itself (e.g., the guest OS and application). This smaller TCB is easier to audit, verify, and reason about, leading to higher assurance.

All CVM security properties are anchored in a Hardware Root of Trust. This is an immutable security engine within the processor that:

• Generates and protects unique cryptographic keys.
• Performs the initial integrity measurements for attestation.
• Enforces the access policies for encrypted memory. It is physically part of the CPU silicon, making it extremely difficult to tamper with. This root of trust is what allows a remote party to have confidence in the CVM's reported security state, as it cannot be forged by software.

A Trusted Execution Environment (TEE) is a secure, isolated area within a main processor. Code and data loaded inside the TEE are protected with respect to confidentiality and integrity, even from more privileged software layers like the OS or hypervisor.

• Hardware Root of Trust: Relies on immutable silicon security to establish a secure foundation.
• Key Capabilities: Provides secure storage, attestation, and isolated execution.
• Implementation Examples: Intel SGX (enclaves), AMD SEV-SNP (encrypted VMs), and ARM TrustZone (secure world). A CVM is a virtualized instance leveraging these underlying TEE capabilities.

Remote Attestation is a critical cryptographic protocol that allows a remote verifier (e.g., a client or a cloud service) to cryptographically verify the integrity and identity of software running inside a TEE or CVM.

• Process: The TEE hardware generates a signed report containing measurements of the initial software state (e.g., bootloader, OS kernel, application). This report is verified against a known, trusted baseline.
• Purpose: Proves that the CVM is running on genuine hardware, has not been tampered with, and is executing the expected, unaltered code.
• Essential for Trust: Enables secure key release and establishes a trusted channel before transmitting sensitive data or credentials to the CVM.

A Hardware Root of Trust is an immutable security engine embedded within a silicon chip (e.g., a CPU or a dedicated security processor) that serves as the foundational, unspoofable source for all security functions in a system.

• Functions: Performs cryptographically verified measurements of system firmware and software during boot, establishing a chain of trust. It also securely generates and stores cryptographic keys.
• Examples: A Trusted Platform Module (TPM) is a discrete chip providing a root of trust. Modern CPUs integrate this functionality (e.g., AMD's Platform Security Processor, Intel's Platform Trust Technology).
• Relation to CVM: The CVM's security guarantees ultimately depend on the hardware root of trust in the underlying server CPU to validate the TEE and perform attestation.

A Secure Enclave is a hardware-isolated trusted execution environment, typically referring to an application-level isolation context within a processor. It protects sensitive code and data at the granularity of a single process or application.

• Granular Isolation: Unlike a full CVM, an enclave often protects a specific library or function within a larger, untrusted application.
• Primary Model: Intel SGX is the canonical example, creating private memory regions (enclaves) encrypted by the CPU.
• Comparison to CVM: A CVM provides isolation at the virtual machine level, protecting an entire guest OS and its applications. A secure enclave provides finer-grained, application-level isolation within a VM or bare-metal system. Both rely on hardware TEEs.