AMD SEV firmware - SEV-ES guest attacking an SNP guest: MULTI-TENANT ISOLATION: Coarse access-control granularity

Impact

MULTI-TENANT ISOLATION: Coarse access-control granularity in SEV firmware lets a privileged attacker create a SEV-ES guest positioned to attack an SNP guest, costing the SNP guest confidentiality. The pattern is worth internalising: mixing SEV generations on one host means the weakest guest type in the mix can become the attack platform against the strongest.

Who can reach it

Requires the ability to launch guests with chosen SEV parameters - the operator or a compromised control plane.

What to do

Fixed in AMD reference firmware (AGESA / PSP / SEV firmware) and delivered only as an OEM SBIOS/BIOS package - Dell, HPE, Supermicro, Lenovo and the ODMs each rebuild and requalify AMD's AGESA drop before shipping. **Expect one to six months of OEM lag**, and on end-of-support platforms expect nothing. Applying it is a drain plus full power cycle, not a driver reload. Verify by reading back the PSP/SMU firmware version afterwards rather than trusting the BIOS version string. This sits inside the SEV-SNP trust boundary, so the update moves the platform's reported TCB version: refresh VCEK certificates from AMD's KDS and update any attestation policy your tenants pin, or confidential guest launches will start failing right after the BIOS lands. Interim control: do not co-schedule legacy SEV/SEV-ES guests alongside SEV-SNP guests on the same host. Pinning confidential-tier workloads to SNP-only hosts removes the attack platform entirely and costs you scheduling flexibility rather than a maintenance window.

References