AMD IOMMU - invalid device table entries bypass SEV-SNP RMP checks: MULTI-TENANT ISOLATION: The IOMMU mishandles

Impact

MULTI-TENANT ISOLATION: The IOMMU mishandles certain special address ranges when the device table entry is invalid, and a privileged attacker with a compromised hypervisor can induce those DTE faults to skip the reverse-map table checks that enforce SEV-SNP page ownership. RMP checks are the mechanism that stops a device DMA from landing in a confidential guest's memory; bypassing them via the IOMMU means DMA-based guest tampering.

Who can reach it

Requires hypervisor privilege plus the ability to drive DMA - so a compromised host with a device (or a device it controls) it can point at guest pages.

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. Particularly relevant on GPU nodes, where large numbers of devices do high-rate DMA and the IOMMU is doing real work rather than sitting idle.

References