Skip to content

SYSTEM Cited by 1 source

Confidential Virtual Machine (CVM)

A Confidential Virtual Machine (CVM) is a hardware-isolated VM instance whose memory, register state, and (with confidential-GPU extensions) accelerator state are inaccessible to the host OS, hypervisor, and cloud operator. The CVM is the VM-granularity realisation of a Trusted Execution Environment (TEE): the guest runs a full Linux-style OS + application stack inside a hardware-enforced boundary, with memory encrypted by the CPU (e.g. via AMD SEV-SNP or Intel TDX) and execution isolation enforced outside the hypervisor's trust boundary.

Meta builds WhatsApp Private Processing on CPU-based CVMs plus Confidential-Compute-mode GPUs, explicitly so that LLM inference (the GPU-side work) is also inside the confidentiality boundary — not just the orchestration code.

Key properties

  • Memory encrypted in hardware — the host cannot read the guest's pages; swap and DMA routes are CPU-gated.
  • Hardware root of trust — the CPU produces an attestation of the loaded binary that a remote party can verify cryptographically, without trusting the host operator.
  • Boot-time + runtime integrity — the TEE can be measured at boot and selected runtime points, so modifications to the loaded image are detectable.
  • Confidential-Compute GPUs — modern datacentre GPUs expose a mode in which the GPU's memory + command queues are similarly isolated, so model weights + activations + outputs stay inside the boundary during inference.
  • Reduced TCB — the host operating system + hypervisor are removed from the trusted-computing base (TCB); only the CPU vendor, the CVM's own software, and the attestation verifier need to be trusted.

What CVMs do NOT solve on their own

  • Code trust — attestation proves which binary is running, not that the binary does what it claims. This is why CVMs are typically paired with a transparency log of acceptable binary digests + open-source + external review.
  • Side-channel attacks — TEE software-exploitation research repeatedly demonstrates bypass capabilities; this is the reason Meta layers defence-in-depth on top of the CVM, not instead of it.
  • Physical attacks — encrypted DRAM + multi-party review close many, not all; Meta explicitly names this residual risk.
  • Correctness of the application inside the CVM — if the app has an exploitable bug, the CVM doesn't help. Containerisation, hardened binaries, log-filtering, minimised input surfaces all address this.

Meta's disclosed CVM surface

From the Private Processing 2025-04-30 post:

  • CPU-based confidential virtualisation technologies — vendor not named (AMD SEV-SNP / Intel TDX / Arm CCA all plausible).
  • Confidential Compute mode GPUs — GPU vendor + generation not named (NVIDIA Hopper CC is the obvious candidate as of 2025-04).
  • Encrypted DRAM — called out explicitly.
  • Remote shell access prohibited — including from the host.
  • Attestation checked against a third-party ledger of acceptable binaries before client session-key release.
  • CVM-to-CVM calls ride the same RA-TLS primitive clients use.

Seen in

Last updated · 319 distilled / 1,201 read