The marketing description of confidential VMs — "your workload is encrypted, even the hypervisor can't read it" — is accurate but incomplete. It describes the data-in-use encryption property without conveying the hardware substrate that makes it possible. Understanding what silicon actually has to implement to enable a confidential VM reveals why not every processor can run confidential compute workloads, why the TCB is more than the CPU, and what the meaningful differences are between AMD SEV-SNP and Intel TDX at the hardware architecture level.
Memory Encryption: The SME/TME Foundation
Both AMD and Intel have shipped general-purpose memory encryption capabilities before their respective confidential compute architectures: AMD Secure Memory Encryption (SME) and Intel Total Memory Encryption (TME). These encrypt all DRAM contents with a key managed by the memory controller, protecting against cold-boot attacks and physical DIMM extraction. The encryption engine sits between the CPU cache and the memory interface, operating transparently to software.
Confidential compute builds on this foundation but adds per-entity encryption keys. AMD SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) can maintain up to a hardware-defined limit of simultaneous encryption key contexts — the exact limit is architecture-specific but in the hundreds for current server generations — each assigned to a distinct guest VM or guest security domain. Intel TDX (Trust Domain Extensions) similarly supports multiple Trust Domain encryption keys managed by the TDX module.
The hardware bookkeeping required for this per-guest encryption is non-trivial. AMD SEV-SNP introduces the Reverse Map Table (RMP), a firmware-managed data structure that records, for every 4 KB page of DRAM, which VM owns that page. The RMP is consulted on every page-table walk: if a hypervisor page-table entry attempts to map a guest's encrypted page to a different entity's address space, the hardware raises an RMP violation. This hardware-enforced page ownership is what prevents the hypervisor from reading guest memory even with full kernel privileges — it is not software policy but hardware enforcement at the memory controller level.
The AMD SEV-SNP Hardware Architecture
SEV-SNP's security properties rest on three hardware components working in concert: the AMD Secure Processor (AMD-SP, a dedicated ARM Cortex-A5 die), the SME memory encryption engine, and the RMP hardware. The AMD-SP is responsible for key management — it holds the encryption keys for each guest VM and manages the VCEK (Versioned Chip Endorsement Key) used for attestation signing. The AMD-SP runs firmware entirely independently of the main x86 cores; a compromised hypervisor cannot write to AMD-SP memory or interrupt AMD-SP execution.
Guest page encryption in SEV-SNP uses AES-128 in a tweaked mode where the physical address of each cache line contributes to the tweak, preventing an attacker from swapping encrypted pages between physical addresses to rearrange guest memory layout. The C-bit (Confidential bit) in the guest page table entry distinguishes encrypted guest memory from non-encrypted shared memory; shared pages (used for hypercall arguments and virtio buffers) are explicitly not encrypted, defining the guest-hypervisor communication interface at a hardware-enforced boundary.
NVM (non-volatile memory, specifically for persistent key material) protection in SEV-SNP is not covered by the base spec — NVDIMM or CXL memory devices attached to a SEV-SNP host are not automatically encrypted with the guest key context. Organizations deploying confidential VMs with persistent encrypted storage must separately ensure that storage encryption (dm-crypt, NVMe namespace encryption) is configured with keys derived from within the confidential VM, not from the hypervisor key management path.
Intel TDX: TD Module Architecture
Intel TDX isolates Trust Domains (TDs) through a software module, the TDX Module, that runs in a new CPU privilege level between the hypervisor (VMXROOT) and the guest (VMXNON-ROOT). The TDX Module is a signed Intel firmware loaded by the platform firmware and verified by the hardware before any TD can launch. This is architecturally different from AMD SEV-SNP: the security boundary in TDX includes the TDX Module code, which is Intel-signed firmware running in x86 address space, whereas in SEV-SNP the AMD-SP is a physically separate processor with its own execution context.
The implications are architectural: TDX security depends on the TDX Module being correct, and the TDX Module is updatable software. Intel has committed to a rigorous security review and attestation binding for TDX Module versions — the module version is included in the TDREPORT structure that attestation quotes are based on — but it is still a software component in the TCB, whereas the AMD-SP firmware has a smaller attack surface by virtue of running on a dedicated core outside the x86 interrupt and exception domains.
TDX's TD-Module memory encryption uses the Multi-Key Total Memory Encryption (MKTME) hardware, extending TME to support per-TD encryption keys. TD memory is protected from the hypervisor via EPT (Extended Page Table) enforcement by the TDX Module — the hypervisor can only map memory that the TDX Module authorizes, and the TDX Module enforces ownership similar to SEV-SNP's RMP.
Side-Channel Isolation: What the Spec Doesn't Fully Solve
Memory encryption and page-table isolation address direct memory access attacks. They do not fully address microarchitectural side-channel attacks — timing channels through shared caches, prefetcher side channels, and cross-TD interference through shared CPU resources. This is the ongoing research frontier for both SEV-SNP and TDX deployments.
The current state: AMD SEV-SNP hosts can be configured to disable simultaneous multithreading (SMT) per guest, eliminating the same-physical-core sharing that enables some hyperthreading attacks. Intel TDX has similar SMT mitigations. However, last-level cache (LLC) side channels between TDs sharing the same physical CPU package are not prevented by either architecture without additional software mitigations (LLC partitioning via Intel CAT/RDT, for example). For workloads with high sensitivity to side-channel leakage — cryptographic operations with key-dependent timing, for instance — deploying on a dedicated physical host or LLC-partitioned domain is the correct posture, not relying on the confidential VM boundary alone.
We're not saying SEV-SNP or TDX side-channel protection is inadequate for most workloads — for the typical enterprise confidential computing use case (protecting multi-tenant application data from a shared hypervisor), both architectures provide a meaningful security improvement. We're saying that any team deploying a cryptographic key management service inside a confidential VM and claiming hardware-equivalent isolation should understand exactly which attack classes the silicon protects against and which require additional architectural controls above the VM boundary.
What a Production Deployment Actually Needs
Putting a confidential VM deployment together for a regulated workload — consider a growing financial services infrastructure team evaluating confidential VMs for a key wrapping service that holds customer data encryption keys — surfaces the silicon requirements quickly. They need: a processor that supports SEV-SNP or TDX; a platform firmware version that enables the feature and includes a compatible PSP (Platform Security Processor) firmware for AMD; a management stack that can retrieve and verify VCEK or PCK certificates; an attestation verifier that can validate the measurement chain against approved reference values; and a deployment process that correctly configures the guest kernel to enable SEV-SNP memory encryption (the mem_encrypt=on kernel parameter and corresponding BIOS settings are not automatic).
The silicon floor is necessary but not sufficient. A team that procures SEV-SNP-capable hardware and deploys guests without verifying that SME is active on all guest pages, that the attestation report is being validated before secrets are released to the guest, and that the VCEK certificate chain is fresh has a confidential VM in name only. The hardware provides the mechanism; correct deployment provides the security property.
The attestation infrastructure, in particular, is frequently underbuilt in first-generation confidential VM deployments. The guest must request an attestation report, an external verifier must validate it, and secrets must be released only upon successful validation. If the key release decision is made by the hypervisor or a host-side service — rather than by a verifier that receives the attestation report and decides to release — the confidential VM boundary has been bypassed at the operational layer.