AMD SEV-SNP - RMP write access during SNP initialization: MULTI-TENANT ISOLATION: There is a window during SEV-SNP

Impact

MULTI-TENANT ISOLATION: There is a window during SEV-SNP initialization in which an admin-privileged attacker can write to the reverse-map table itself. Corrupting the RMP at init time means the ownership map that governs every subsequent guest page assignment starts out wrong - the attacker can arrange for guest pages to be host-writable from the moment the platform comes up, and no later check catches it because the check is the RMP.

Who can reach it

Local, admin-privileged, and specifically during SNP platform initialization - so an attacker who controls the host boot sequence or the SNP init path.

What to do

Fixed in AMD SEV firmware / AGESA and reaches you as an OEM SBIOS package - AMD hands AGESA to Dell, HPE, Supermicro, Lenovo and the ODMs, who each requalify before shipping BIOS. **Budget one to six months of OEM lag**, longer on older platforms and sometimes never on end-of-support SKUs. Applying it means draining the host and doing a full power cycle. Because the fix moves the platform's reported SEV-SNP TCB version, you must also pull fresh VCEK certificates from AMD's Key Distribution Service and update any attestation policy your tenants pin - otherwise guests will start failing launch validation the moment the BIOS lands. Some SEV firmware can alternatively be staged from linux-firmware (amd/amd_sev_*.sbin) and committed via the ccp driver at boot, which is faster than waiting on BIOS - check whether your platform supports firmware hot-load before assuming the OEM is the only route. Since the exposure is at SNP init, the practical control is boot integrity: measured boot on the host, and refusing to admit confidential tenants onto nodes whose boot chain you cannot attest.

References