AMD SEV-SNP firmware (EPYC Milan, Genoa, Bergamo, Siena): SNP firmware fails to restrict where a hypervisor-driven

Impact

SNP firmware fails to restrict where a hypervisor-driven write can land, letting a malicious host overwrite a confidential guest's memory or the UMC seed that derives that guest's memory encryption key. Overwriting guest memory defeats the integrity half of SNP outright; overwriting the UMC seed lets the operator choose the key material protecting a tenant. This is the highest-severity item in the AMD-SB-3011 batch and it is squarely an operator-versus-tenant break - the exact threat model a customer pays the SNP premium for.

Who can reach it

Malicious hypervisor / host root issuing SNP firmware commands against a running confidential guest. Local, high privilege.

What to do

Two options per AMD-SB-3011: hot-loadable SEV firmware (1.37.14 hex on Milan, 1.37.24 on Genoa) which does NOT require a reboot, or a full Platform Initialization / BIOS flash (MilanPI 1.0.0.D, GenoaPI 1.0.0.C) which does. Take the SEV firmware path first to close the window without draining training jobs, then fold the PI update into your next maintenance cycle. Fixing it moves the SNP TCB version above 0x16 (Milan) / 0x15 (Genoa), which changes every attestation report the host issues - tenants' verifiers must be updated to accept the new TCB or their attestation will start failing.

References