Confidential Computing and Hardware Memory Encryption Architecture: AMD SEV-SNP, Intel TDX, and AES-128-XTS DRAM Bus Cryptography

In multi-tenant cloud infrastructure, traditional virtualization security models rely on the implicit assumption that the host hypervisor (Ring -1 / KVM / Xen) and data-center physical administrators are inherently trustworthy. However, privileged hypervisor compromises, cold-boot DRAM extraction, and passive interposer probing across DDR5 dual in-line memory module (DIMM) buses expose plaintext guest memory directly to host-level adversaries. Confidential Computing eliminates the hypervisor from the Trusted Computing Base (TCB) by embedding inline, hardware-enforced cryptographic engines directly inside the CPU die's integrated memory controller (IMC). Through architectures such as AMD Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) and Intel Trust Domain Extensions (TDX), every cache line evicted to external DRAM is encrypted with ephemeral, per-VM silicon keys and protected against ciphertext replay, memory aliasing, and page-table remapping attacks.

1. Inline Memory Controller Cryptography: AES-128-XTS & Physical Address Tweaking

Encrypting multi-terabyte server DRAM footprints at DDR5-6400 memory bus speeds requires a cryptographic primitive capable of random 64-byte cache-line access without cipher-block chaining dependencies or expansion tags that alter standard DIMM capacity. Both AMD EPYC and Intel Xeon Scalable processors implement inline AES-128-XTS (XOR-Encrypt-XOR-based Tweaked-Codebook Mode with Ciphertext Stealing) engines directly inside the silicon path between the Last-Level Cache (LLC) and the physical DDR5 PHY channels.

To prevent identical 64-byte plaintext blocks located at different physical memory addresses from producing identical ciphertexts (which would leak structural memory patterns to an attacker observing the memory bus), the inline encryption engine incorporates the System Physical Address ($\text{SPA}$) as a cryptographic tweak input alongside an ephemeral 128-bit encryption key managed exclusively by an on-die security coprocessor and indexed by the guest virtual machine's Address Space Identifier ($\text{ASID}$) or KeyID.

2. Mitigating Hypervisor Page-Table Remapping: AMD SEV-SNP Reverse Map Table (RMP)

First-generation memory encryption (such as original AMD SEV and SEV-ES) protected memory confidentiality against passive physical probing, but lacked cryptographic integrity protection against an active, malicious hypervisor. Because the host hypervisor manages the second-level Nested Page Tables (NPT / EPT) that translate Guest Physical Addresses ($\text{GPA}$) into System Physical Addresses ($\text{SPA}$), a compromised hypervisor could remap two different $\text{GPA}$ pointers to the same underlying $\text{SPA}$ (an aliasing attack) or replay old ciphertext pages to corrupt guest control flow.

AMD SEV-SNP (Secure Nested Paging) closes this attack surface by introducing a hardware-enforced Reverse Map Table (RMP) stored in reserved system DRAM. Indexed by every $4\text{ KB}$ block of System Physical Address space, the RMP maintains a strict $1:1$ inverse mapping ($\text{SPA} \mapsto \{\text{Owner ASID}, \, \text{Target GPA}, \, \text{Validated Bit}, \, \text{Page Permissions}\}$):

1. Hardware TLB Walk Verification: At the end of every nested page table walk, the CPU's Memory Management Unit (MMU) queries the RMP entry for the resolved $\text{SPA}$. If the RMP entry's recorded $\text{ASID}$ and $\text{GPA}$ do not exactly match the guest VM performing the memory access, the CPU aborts the instruction and raises a synchronous #PF (RMP Violation) fault.
2. Guest-Executed `PVALIDATE` Instruction: Before a Confidential VM uses any newly allocated memory page, the guest kernel must explicitly execute the privileged PVALIDATE instruction to set the RMP entry's Validated bit. If a malicious hypervisor attempts to unmap and swap the page without guest consent, the validation bit clears, triggering a #VC (VMM Communication Exception) inside the guest.

3. Architectural Comparison: AMD SEV-SNP vs. Intel TDX vs. ARM CCA

Cloud infrastructure security architects evaluate silicon confidential computing implementations across five hardware isolation and attestation dimensions:

4. Intel TDX Architecture: Secure Arbitration Mode (SEAM) & Cryptographic ECC MACs

Whereas AMD offloads key management and attestation to an independent on-die Secure Processor, Intel Trust Domain Extensions (TDX) introduces a new CPU privilege mode called Secure Arbitration Mode (SEAM), which hosts a digitally signed, CPU-attested micro-hypervisor module (`Intel TDX Module`) residing in hardware-isolated range registers (`SEAMRR`).

To enforce cryptographic memory integrity alongside confidentiality, Intel's Multi-Key Total Memory Encryption (MKTME) engine repurposes unused bits within standard server DDR5 Error-Correcting Code (ECC) metadata to embed a 28-bit SHA-3 / cryptographic Message Authentication Code (MAC) on every 64-byte cache line. If an attacker or compromised host hypervisor modifies a single bit of ciphertext in physical DRAM or attempts to transplant a ciphertext cache line from another address, the memory controller's inline MAC verification fails upon cache-line fill, poisoning the cache line and raising an unrecoverable hardware fault before corrupted data reaches the CPU execution pipeline.

Primary Silicon Security Specifications & Architecture References

• 1. Advanced Micro Devices (AMD) White Paper: AMD SEV-SNP: Strengthening VM Isolation with Integrity Protection and Reverse Map Tables (RMP).
• 2. Intel Corporation Architectural Specification: Intel® Trust Domain Extensions (Intel® TDX) Module Base Architecture & MKTME Cryptographic Specification.
• 3. Confidential Computing Consortium (Linux Foundation): Hardware-Based Trusted Execution Environments (TEEs) and Remote Attestation Architecture Reference.