SECURITY / CONFIDENTIAL VMs

Who can touch a confidential VM's memory?

In an ordinary VM the host can read and change every byte of the guest. A confidential VM (AMD calls its design SEV-SNP) keeps the host out: its pages are encrypted with the VM's own key, and a table the host can change only through instructions such as RMPUPDATE, never by writing it, the Reverse Map Table (RMP), records who owns every page of RAM. A guest address (GPA) still becomes a real one (SPA) through a table the host owns (the CPU's nested page table; the IOMMU has its own, the stage 2 of the virtual IOMMU page), but the host is no longer trusted: the RMP is checked after it. Write a secret, then let the host try its luck.

Which experiment answers my question?

Each link opens the chapter's experiments; pick the named one from the menu
Question	Start with
Does changing the address move the bytes?	Receive: watch the whole timeline
Can sharing expose more than my message?	Share a page, share everything on it
Can private input still be rejected, or change after I checked it?	Received is not trusted, then An approval can expire
Does a valid mapping authorize a private page?	Same GPA, different guests, The right owner, the wrong page, A shared page yes, a private page no
Is a device in RUN trusted with my data?	RUN is not permission, A device has a privilege level too
Does repairing a mapping finish recovery?	A fence outlives the repair
Does a valid signature authorize releasing a secret?	Release a secret only to the attested session
Does encryption catch tampering and replay?	Protect the record, not just the memory
Does an error undo what already happened?	A failed mapping already copied the secret, Half a transfer is still half done

What claims does this page make? 3 points

Platform assumption: the RMP states, fault bits and instructions come from AMD's SEV-SNP white paper and Linux, and can differ by CPU generation and kernel version.
Teaching model: the experiments use a small model with 16 or 32 bytes per page and a stand-in for ciphertext, not AES or AMD's RMP entry format.
Platform assumption: the Intel TDX and Arm CCA table only repeats Linux kernel documentation and is not modelled.

Experiments

Words used in the experiments

Host, hypervisor: The software that runs the VM. Here it is not trusted with the VM's data.
GPA, SPA: Guest-physical address (the VM's idea of RAM) and system-physical address (RAM in the usual case, a peer device's memory on a peer-to-peer path). The host's nested table maps one to the other.
ASID: The number that names a guest and selects its memory-encryption key. A is ASID 1, B is ASID 2.
RMP: Reverse Map Table: one entry per 4 KiB page of RAM saying who owns it, at which GPA, and whether the guest has validated it.
C-bit: A bit in the guest's own page table: 1 for a private (encrypted) access, 0 for a shared one.
RMPUPDATE, PVALIDATE, RMPADJUST: Instructions: the host assigns a page; the guest accepts it; a guest privilege level passes page permissions down.
VMPL, SVSM: Privilege levels inside one VM, 0 (most) to 3. A Secure VM Service Module often runs at VMPL0 and the guest kernel below it.
#PF, #NPF, #VC: A page fault (the host's, in the examples here, though one can also arise in guest execution), a nested page fault the host handles for the guest, and the guest's own VMM Communication exception.
VMSA, GHCB: The VM's saved registers (protected), and a page the guest shares to pass chosen values to the host.

Choose an experiment (core: start here; deeper: more cases; reference: catalogue)

Experiment

The latest access: which address, which record

Bytes at offsets 0x120 to 0x13f of A's page, as A reads them

Without JavaScript, a worked example: A writes 16 bytes at GVA 0x400000120. The guest page table gives GPA 0x200120, the nested table gives SPA 0x80000120, and the RMP row for SPA page 0x80000000 (owner A, expects GPA 0x200000, validated, VMPL0 rwx) passes every check, so only the 16 bytes at +0x120 change.

Intel and Arm:

The RMP, scene by scene

Each scene runs the same teaching model as the experiments above, on ordinary 4 KiB private pages with synthetic addresses. Every table is the model's own record after your last action. Not modelled: large pages, special pages, migration, and a real RMP entry layout.

The scenes need JavaScript. Worked example without it (RMP-02): guest A has GVA 0x400000000 and GVA 0x500000000 both mapped to GPA 0x200000, so both reach SPA 0x80000000, whose RMP row expects GPA 0x200000: both are good names. The host also maps GPA 0x201000 onto the same SPA and A has a name, GVA 0x700000000, for it: that name reaches the same SPA but the row expects GPA 0x200000, so a write through it is refused and the bytes stay.

Worked example from the fixture, not run in this browser (RMP-03). Guests A and B both read GPA 0x200000. A reaches SPA 0x80000000 and B reaches SPA 0x90000000, each row owned by its own guest, and both read SAME-PLAINTEXT!!. The host then redirects only B's nested mapping to A's page: B's read is refused with #NPF (RMP, ENC): SPA 0x80000000 belongs to A (ASID 1), not to B (ASID 2), even though the GPA matches. Neither page changes.Worked example from the fixture, not run in this browser (RMP-04, destination owned by another guest). A reads GPA 0x200000 and gets A-DATA-v1-------. The host remaps A's GPA 0x200000 to SPA 0x90000000, a page of guest B. No RMP row changes, and the old page at SPA 0x80000000 still holds A-DATA-v1-------. The same read is now refused at the owner check: #NPF (RMP, ENC): SPA 0x90000000 belongs to B (ASID 2), not to A (ASID 1). The other two destinations fail at the GPA check and at the validated check.Worked example from the fixture, not run in this browser (RMP-05). The host assigns SPA 0x80000000 to A at GPA 0x200000: GUEST-INVALID. A's read is refused (#VC): assigned but never validated. A validates it (PVALIDATE): GUEST-VALID, VMPL0 rwx, VMPL1 to 3 none. A initializes the page with a 16-byte write of initialized-page. VMPL0 sets VMPL1 to rw- (RMPADJUST), and the kernel at VMPL1 then reads initialized-page. Releasing the page is conceptual, not executable: this model has no quiescing, so nothing can convert it back.Worked example from the fixture, not run in this browser (RMP-06). The kernel (VMPL1, CPL0) reads its buffer at GPA 0x400000 and gets caller-buffer-v1. Its write is refused: VMPL1 has r-- on this page. It cannot grant itself write or grant VMPL0 write (RMPADJUST only changes a less privileged VMPL), cannot validate (only VMPL0 validates), and cannot grant VMPL2 write it does not hold. VMPL0 grants VMPL1 read and write: VMPL1 now has rw-. CPL never selects a VMPL row.Worked example from the fixture, not run in this browser (RMP-07). Three engines, three fixtures, no shared byte count. The CPU path: guest A reads private GPA 0x200000, passes all five checks and reads account-token=42. An ordinary device writing A's private page at SPA 0x100002000 is refused (RMP_PAGE_FAULT, flags=0x2) and the page still holds PRIVATE-DATA-A!!. The trusted-device path without a grant is refused: guest A has not granted private DMA. With the grant, the write lands: 0x100002000 holds RX-TRUSTED-00001.

What each side holds after that step

The latest guest access, check by check

RMP · changed only by instructions; pages not listed are HYPERVISOR

Nested tables · the host edits them

RAM as the host reads it

What software read

Faults

The model keeps 16 or 32 bytes per page. Its "ciphertext" is a stand-in that changes with the key and the address, not AES, and its RMP lines are the white paper's fields, not AMD's packed entry. Not modelled: 2 MiB RMP entries, the Immutable states other than FIRMWARE, SNP guest messages and interrupts, execute checks, and when permissions are first set: the 2020 white paper has the guest's first PVALIDATE give VMPL0 full access and the others none, as modelled here, but a newer APM revision (24593 rev 3.44, §15.36.7) is reported to set initial permissions when the page is assigned, so treat the exact instruction an experiment credits as the white paper's, not the current manual's. Devices come next: can a device reach private memory?

A page's life: the RMP states

The RMP is "a single data structure shared across the system that contains one entry for every 4k page of DRAM that may be used by VMs". Each entry puts its page in one of eight states. Instructions move a page between the first three; the AMD Secure Processor (AMD-SP, also called the ASP or PSP) owns the immutable ones.

State	What it means (white paper, Table 3)
HYPERVISOR	Default for unassigned memory: the host's own, non-SNP VMs' and shared (C=0) memory.
GUEST-INVALID	Assigned to a guest, not yet usable: the guest has not validated it.
GUEST-VALID	Assigned and usable as the guest's private (C=1) memory.
PRE-GUEST, PRE-SWAP	Immutable; PRE-GUEST not validated, PRE-SWAP validated.
FIRMWARE, METADATA, CONTEXT	Immutable pages the AMD-SP uses for itself, for swap metadata and for per-VM data.

One read, all the way

Guest A reads GVA 0x4000_0120 (the study notes' E09):

Guest page table (the guest's): GVA → GPA 0x0020_0120.
Nested table (the host's): GPA → SPA 0x8000_0120; the offset 0x120 survives both.
RMP entry for SPA page 0x8000_0000: owner A, GPA page 0x0020_0000, validated, 4 KiB, VMPL0 may read. Every check passes.
RAM: the memory controller decrypts with A's key. A sees its plaintext.

The RMP is not another translation step: it does not change the address, it decides whether the one the tables produced may be used. Two guest virtual addresses that reach the same GPA are fine (E11); two GPAs that try to use the same private page are not, because the RMP entry names exactly one GPA.

Which fault is which

You see	Who gets it	Here it means
`#PF` (RMP)	the host	The host wrote a page the RMP gives to a guest or the AMD-SP.
`#NPF`, RMP bit (31)	the host, for the guest	The page's owner or GPA does not match the access, or the C-bit does not match the page's state. Linux names the bits `PFERR_GUEST_RMP_MASK` and, for a C=1 access, `PFERR_GUEST_ENC_MASK` (34).
`#NPF`, VMPL bit (36)	the host, for the guest	This VMPL lacks the permission (`PFERR_GUEST_VMPL_MASK`).
`#VC`	the guest	The page is assigned but not validated. Also raised for instructions the host would intercept (CPUID, MSR and I/O accesses); the #VC handler then asks the host through the GHCB. So it is not an error in general.
`RMP_PAGE_FAULT`	the IOMMU's event log	A device's access failed the RMP check: see secure DMA.
A rejected length	guest software	A protocol check (E08, E16). Not a hardware fault at all.

SME, SEV, SEV-ES and SNP: what each adds

Name	Protects	Does not by itself give
SME, TSME	What DRAM holds: memory encrypted with a host key (TSME without the OS choosing pages).	Any protection from the host's own software.
SEV	A VM's memory, with its own key.	Protection from a host that remaps or rewrites pages.
SEV-ES	The VM's saved registers (VMSA) across exits.	Integrity of the rest of RAM.
SEV-SNP	Integrity too: the RMP, validation, VMPLs, attestation.	Trust in devices: see trusted I/O.

Two names often merged: a memory-encryption key (SME-MK on AMD, MKTME on Intel) chooses how memory is encrypted, while a protection key (MPK, PKU) only switches access rights; it encrypts nothing (E05). And two host keys do not make two confidential VMs: ownership, validation and evidence are separate records (E04).

Intel TDX and Arm CCA

The same questions, other designs. This guide describes them only as far as the sources below say; it has no model of either.

	AMD SEV-SNP	Intel TDX	Arm CCA
Protected VM	SNP guest	Trust domain (TD)	Realm
Trusted manager	AMD-SP firmware	The TDX module, "a CPU-attested software module"	The Realm Management Monitor (RMM)
Private or shared	C-bit and RMP state	"a bit in its page table entries"	Protected lower half of the IPA space, shared upper half
Accepting memory	PVALIDATE	Private pages must be accepted before use; premature access causes a #VE or a TD exit according to configuration (Linux normally disables these private-memory #VEs)	RIPAS RAM or EMPTY, requested through RSI
Host touches private memory	#PF on a write; reads see ciphertext	The host cannot access it	"cannot be seen by the Normal World"
Device DMA today	Shared bounce buffers (SWIOTLB)	"TDX uses SWIOTLB for most DMA allocations"	Bounce buffers in the shared half

Sources

AMD, SEV-SNP: Strengthening VM Isolation with Integrity Protection and More, white paper, January 2020 (publisher PDF): RMP checks, Table 3, Figures 4 to 6, VMPLs.
Linux: arch/x86/include/asm/kvm_host.h (PFERR_GUEST_*), arch/x86/include/asm/sev.h; AMD memory encryption; SNP support under an SVSM (LWN).
Intel Trust Domain Extensions and Arm Confidential Compute Architecture, Linux kernel documentation.
The author's own study notes on confidential computing, written from AMD's public documents (not published), examples E01 to E14 and W19 to W20.