AMD SEV firmware - ASID range enforcement between SEV-ES and SEV-SNP guests: MULTI-TENANT ISOLATION: A malicious

Impact

MULTI-TENANT ISOLATION: A malicious hypervisor can launch a SEV-ES guest using an ASID from the range reserved for SEV-SNP guests. ASIDs key the memory encryption, so overlapping the ranges lets a weaker-protected ES guest sit where an SNP guest's protections were assumed - a partial confidentiality loss for the SNP tenant. The interesting part is that the attack uses a legitimate hypervisor operation with an out-of-range parameter rather than any memory-safety bug.

Who can reach it

Requires hypervisor privilege and the ability to launch guests - i.e. the cloud operator or anyone who compromises the control plane.

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.

References