Confidential Virtual Machines

• Confidential Virtual Machines are VMs with isolated and cryptographically protected memory, CPU state, and control flow, using trusted hardware-based TEEs.
• They leverage primitives like AMD SEV-SNP, Intel TDX, and Arm CCA to secure sensitive workloads against observation and tampering by hypervisors and other VMs.
• Recent innovations focus on attestation, composability, I/O efficiency, and formal verification to meet evolving security demands in cloud environments.

A Confidential Virtual Machine (CVM) is a virtual machine in which the entire memory, CPU state, and control flows of the guest OS and all applications are isolated and cryptographically protected against both the host hypervisor and other VMs, using hardware Trusted Execution Environment (TEE) primitives such as AMD SEV-SNP, Intel TDX, or Arm CCA. CVMs are increasingly used to secure sensitive workloads from observation and tampering by privileged software, providing attestation and confidentiality guarantees that extend beyond standard virtualization. Recent research addresses critical aspects including attestation, composability, device and network I/O, side-channels, privilege separation, trust models in public cloud environments, and the evolution toward verified security monitors.

1. Foundations and Architectures of Confidential Virtual Machines

CVMs generalize the enclave abstraction from page-granular or application-granular TEEs (e.g., Intel SGX) to full-VM protection. The threat model explicitly removes the hypervisor and provider software from the Trusted Computing Base (TCB), instead placing trust solely in the CPU vendor’s on-die secure engine (e.g., AMD-SP, Intel QNC, Arm CCA Realm Management Monitor).

Key hardware properties include:

• Memory encryption and integrity: Per-VM keys encrypt all guest DRAM (e.g., AES-XTS under SEV-SNP), with integrity provided by Merkle-tree or counter-tree MAC structures.
• CPU state protection: Register and control block state auto-encrypted on VMEXIT/VMRUN (e.g., VMCB/VMSA for AMD, VMCS for Intel).
• Hardware-enforced privilege separation: Multiple privilege levels (e.g., VMPL in SEV-SNP) and memory tagging (RMP, GPT) enforce access control over guest memory pages and devices.
• Hardware-secured attestation: CPUs sign measurements of VM content and launch state, enabling remote verification against known reference values.

These hardware primitives permit formal models that abstract the privilege-layering and memory isolation guarantees, as in the verified security monitor approach which isolates the SM in the highest privilege mode and mathematical axioms specify the permitted transitions, memory partitions, and interrupt routing (Ozga et al., 2023). Tyche generalizes this with a capability-based monitor for trust domains, collapsing multiple stacks of TCBs into one enforceable isolation root (Ghosn et al., 16 Jul 2025).

2. Attestation, Trust, and the Cloud Deployment Model

Attestation is fundamental: CVM platforms provide cryptographically signed evidence tying the loaded firmware, kernel, disk, and optionally application code to a hardware root of trust (HRoT). Measurements are atomically performed by the TEE at boot, and the attestation report includes chip identifiers and a vendor-signed certificate chain (e.g., Cert_{VCEK}, Cert_{PCK}) (Galanou et al., 23 Feb 2024, Eisoldt et al., 11 Mar 2025).

A central challenge in cloud deployments is that providers retain significant control over critical parts of the TCB (paravisors, virtualized TPMs, hypervisor-embedded measurement agents), often violating the ideal threat model where the provider is strictly untrusted (Eisoldt et al., 11 Mar 2025). Clouds also typically interpose on attestation flows, limiting tenants’ ability to verify hardware state or firmware integrity directly.

To close this gap, research proposes external vTPM (ephemeral or root-managed) architectures (Narayanan et al., 2023, Mao et al., 2 May 2024), proof-of-chassis binding using vTPM-anchored PCR sealing and cross-referenced TPM/TEE reports (Rezabek et al., 14 Oct 2025), and direct hardware-rooted attestation channels. Integrating a Protected Platform Identifier (PPID) into quote evidence links a CVM to a physical operator, supporting extended threat models that include physical-level attacks (Rezabek et al., 17 Jun 2025).

Recent frameworks such as Revelio operationalize direct end-user attestation via browser-integrated protocols, reproducible builds, root filesystem integrity verification, and TLS key binding to the attested VM state (Galanou et al., 23 Feb 2024).

3. Privilege Separation, Enclave Composition, and Application Containment

The extension of privilege separations within the CVM has produced new methods of enforcing least privilege:

• VMPL-based isolation (Cabin, NestedSGX): SEV-SNP’s VMPL allows domain-specific write/execute privileges to be applied to pages, confining untrusted code (user apps or entire enclaves) to lower privilege levels, mediating system calls via proxy kernels (VMPL1), and preventing direct access to the core OS code/data (VMPL0) (Mei et al., 17 Jul 2024, Wang et al., 18 Feb 2024).
• Enclave-in-CVM composition: NestedSGX leverages VMPL to emulate an SGX-like model, providing measured, remotely attestable enclaves inside an already-attested confidential VM. Enclaves are managed and measured by a security monitor running at VMPL0, compatible with existing SDKs, with negligible overhead on compute/memory-intensive tasks (<2%) and modest overhead in I/O-heavy workloads (<16%) (Wang et al., 18 Feb 2024).
• Unified Trust Domain abstractions (Tyche): Provides recursive, composable isolation among VMs, enclaves, and sandboxes by capability partitioning and signed attestations encoding the domain tree structure. This significantly reduces TCB size by eliminating layering of virtualization and enclave frameworks (Ghosn et al., 16 Jul 2025).

4. Inter-CVM Communication, Device I/O, and Elastic Resource Management

Traditionally, CVMs enforce strictly disjoint memory models, requiring encrypted, hypervisor-accessible shared buffers for inter-VM communication. This results in substantial cryptographic overhead and performance bottlenecks.

• CAEC with Arm CCA: Extends Arm CCA firmware to support Confidential Shared Memory (CSM), allowing select pages to be mapped into multiple realms’ address spaces while preserving confidentiality from the hypervisor and non-participating CVMs. CAEC achieves up to 209× performance improvement over encryption-based data sharing, enables RAM deduplication in multi-VM LLM inference, and provides formal attestation of CSM’s participants (Abdollahi et al., 1 Dec 2025).
• Elastic CVMs (Ditto): Introduces the Worker vCPU abstraction, enabling fine-grained, hypervisor-assisted runtime scaling of vCPUs entirely within the CVM’s TEE boundary. Wake/sleep latency is minimized (∼14 μs vs. ~35 ms for hotplug), maintaining full register and memory confidentiality (Zhao et al., 23 Sep 2024).
• Device and network I/O: Trusted I/O-based approaches are limited by their unnecessary duplication of security functions (e.g., PCIe link encryption yields negligible benefit for network since IPsec/TLS are obligatory). Software-only data plane solutions (FOLIO) with DPDK can reach within 6% of the hypothetical hardware-optimal throughput for SEV-SNP VMs, without expanding the TCB to include device firmware (Li et al., 5 Mar 2024).

Device interfaces (MMIO, PIO, DMA) remain a security-critical attack vector, as hardware protections do not authenticate device responses or DMA operations. The VIA tool demonstrates large bug surfaces in Linux drivers exploitable by malicious hypervisors and motivates hardware-enforced descriptor bounds and language-level driver sanitization (Hetzelt et al., 2021).

5. Threat Model Limitations: Side-Channels, Interrupts, and Deployment Gaps

CVM architectures typically omit side-channel mitigation from the formal model: cache, page-fault, performance-event, and ciphertext-based leaks remain the developer’s responsibility (Zhang et al., 18 Jun 2025). FARFETCH’D quantifies such leakage, demonstrating high-throughput covert channels (~0.5 Mbit/s), successful key fingerprinting, and the efficacy of differential privacy dummy padding and oblivious access algorithms in real deployments.

Interrupt virtualization is another overlooked interface: the Heckler attack exploits unrestricted (non-timer) interrupt injection to subvert control and data flow inside the CVM (breaking OpenSSH and sudo authentication, corrupting ML pipelines). Existing hardware does not provide the guest with granular interrupt filtering, highlighting the need for hardware-level selective blocking and exposing explicit-effect vectors (Schlüter et al., 4 Apr 2024).

Attestation workflows often lack cryptographic binding to provider identity or physical location. Current standards require standardization of PPID embeddings and provider inventories; otherwise, end users remain unable to assess physical compromise risk (Rezabek et al., 17 Jun 2025). Furthermore, public cloud providers’ opaque TCB components and interposed attesters undermine the original confidentiality/integrity trust model (Eisoldt et al., 11 Mar 2025).

6. Formal Methods and Verified Security for CVMs

A formally verified SM refines the security model to a set of architectural axioms—privilege hierarchy, secure boot, memory isolation, interrupt routing, hardware seed derivation, etc.—and builds an invariance-preserving FSM over state transitions between hypervisor, SM, and CVM environments. Coq-embedded proofs and type-state modeling (in Rust, for instance) guarantee non-interference and integrity properties (Ozga et al., 2023). Tyche’s approach similarly offers provably minimal TCB and composable domain isolations.

Future work involves formalizing shared memory protocols (e.g., CSM), verifying dynamic attestation flows, hardening interrupt delivery, and extending cross-architecture portability (x86, Arm, RISC-V), as well as compositional attestation chains across nested trust boundaries.

7. Future Directions, Limitations, and Open Challenges

Research converges on several remaining gaps and priorities:

• Standardizing and extending attestation protocols to support cryptographically verifiable platform and identity binding, end-user validation, and continuous runtime integrity assessment (e.g., periodic in-guest PCRs tied to external roots).
• Advancing hardware support for device-driven attack surface minimization, interrupt filtering, and defended I/O virtualization.
• Developing practical, high-assurance, and performant approaches to mitigate side-channels (cache, page-fault, ciphertext dynamics) without incurring prohibitive overhead or breaking application compatibility.
• Designing portable, verified isolation monitors and attestation frameworks adaptable across TEE architectures and cloud providers.
• Enhancing compatibility with composed trusted domains and orchestrating resource management and data sharing among mutually distrustful tenants within a unified, attested security boundary.

Despite rapid progress, CVMs currently do not offer complete secrecy against hypervisor-rooted I/O and side-channel attacks, nor do cloud platforms fully relinquish trust over the attestation flow and virtualization stack. A shift toward minimized, verified isolation roots, open attestation, and cross-layer composable trust semantics remains necessary for the next phase of confidential cloud computing (Ghosn et al., 16 Jul 2025, Abdollahi et al., 1 Dec 2025, Eisoldt et al., 11 Mar 2025, Zhang et al., 18 Jun 2025, Zhao et al., 23 Sep 2024).