ASAravind Sivakumaran
Theme

Theme and appearance

Appearance
Palette

Pick any colour. The displayed accent adjusts for readable contrast in light or dark mode.

← IOMMU star map

SECURITY / THE WHOLE PLATFORM

What does SNP not cover?

The chapters before showed what SEV-SNP enforces. This one is about its edges: a feature that exists is not a feature that is on, a signed report is not a verified claim, and a VM that the host cannot read can still overflow its own buffer. The first experiments gather evidence one layer at a time, from the processor up to the verifier; the rest test names and limits.

What claims does this page make? 3 points
Five layers of evidence: hardware, firmware, host, guest, verifier. Hardwaresupported Firmwareinitialized Hostenabled Guestselected Verifierverified

Experiments

Words used in the experiments
Supported, enabled, selected, verified
The hardware can; the platform turned it on; this guest uses it; the evidence meets a verifier's policy.
RMPOPT
An optimization that lets the CPU skip RMP lookups for a large region known to hold no guest pages (Linux RMPOPT patches).
RMP dirty status, RMPCHKD
An RMP extension that tracks whether a guest page was written, and the instruction that checks it (AMD 69203, RMP Dirty, revision 1.00).
Secure TSC
A time-stamp counter the host cannot change for an SNP guest.
Restricted injection, #HV
An SNP mode where the host may inject only one exception, #HV, which tells the guest to check for pending events itself.
NX, SMEP, SMAP
No-execute pages, and kernel protections against running or touching user-space pages.

Experiment

    Intel and Arm:

    What is known after that step

    Each layer's claim

      Pages and metadata

        Notes

          Four claims, four kinds of evidence

          ClaimMeansEvidence
          SupportedThe hardware or firmware can do itCPUID, IOMMU feature registers, firmware feature discovery
          EnabledPlatform set-up turned it onInitialization status, host kernel parameters
          SelectedThis guest or device uses itThe guest's report, the device's binding and grant
          VerifiedA relying party checked the evidence against its policyA verifier's decision, with the policy it used

          The firmware's feature table (FEATURE_INFO, in a CPUID-shaped namespace) is not the same as running CPUID yourself; follow the firmware and guest paths the specifications give.

          SNP extensions: discover, then verify

          FeatureWhat it is forWhat it is not
          Segmented RMP, RMPOPTLaying out and speeding up RMP metadataA weaker ownership check
          RMP Dirty, RMPCHKDTracking writes to private pagesProof that the bytes are good
          Restricted and alternate injectionLimiting how the host signals events (#HV)Guaranteed delivery
          Secure TSCA time counter the host cannot adjustA calendar, or scheduling
          Secure AVIC (CPU)Interrupt virtualization for SNP guestsDevice interrupts bypassing the host (§2.14.6)
          Ciphertext hiding, RAPL disable, SMT policyNarrowing side channelsRemoving all of them
          AES-256-XTS policyA stronger memory-encryption modeAuthenticated encryption
          CXL policyWhich CXL memory may be usedOne rule for CXL.io, .cache and .mem

          Two compatibility checks that are easy to merge: SNP firmware 1.59 rejects ciphertext hiding while CXL memory is present (E45, from the reference), and the IOMMU relies on firmware to keep CXL devices with a .cache interface off SNP systems (48882 §2.13). Post-quantum signatures (LMS) in a boot path do not make an application's TLS post-quantum (E48).

          Still the guest's job

          Intel and Arm names

          NameWhat it isClosest idea here
          TME, MKTME (Intel)Memory encryption, one or several keysSME, SME-MK
          TDX, TD (Intel)Confidential VMs managed by the TDX moduleSEV-SNP guests
          SGX (Intel)Enclaves inside a process, not whole VMsnone
          CCA, RME, Realm, RMM (Arm)Confidential VMs managed by the Realm Management MonitorSEV-SNP guests and the AMD-SP
          GPT, GPC (Arm)Granule protection tables and checks (Arm's RME documentation, not read for this guide)The RMP, with a different format
          SMMU (Arm)Arm's IOMMU (notes)The AMD IOMMU
          VT-d (Intel)Intel's IOMMU; Linux logs it as DMAR (names)The AMD IOMMU
          PAC, MTE, BTI (Arm)Pointer, memory-tag and branch defencesGuest software defences, not encryption

          Port the question, not the register names: "a device must not write another guest's memory" carries over; RMP fields do not become GPT fields (E53).

          Look at your own machine

          A read-only look at a Linux host. It enables nothing, reads no keys, touches no MSRs and tests no isolation; what it prints is "supported" or "enabled" at most. Treat its output as private. 

          uname -r
grep -o -w -E 'sme|sev|sev_es|sev_snp|nx|smep|smap|pku|user_shstk|ibt' /proc/cpuinfo | sort -u
ls -l /dev/sev /dev/sev-guest /dev/tpm0 /dev/tpmrm0 2>/dev/null
grep -H . /sys/module/kvm_amd/parameters/sev* 2>/dev/null
dmesg | grep -i -E 'SEV|SNP|AMD-Vi' | tail -n 20   # may need root

          Sources