AMD SEV / SEV-ES - guest address space rearrangement undetected by attestation: MULTI-TENANT ISOLATION: A malicious

Impact

MULTI-TENANT ISOLATION: A malicious hypervisor can rearrange memory in the guest's address space and the SEV attestation mechanism does not notice, because attestation measures content rather than placement. That lets the host reorder the guest's own encrypted pages to build a different program out of the same measured bytes - the attestation report still validates while the VM executes something the tenant never wrote. This is the failure that makes 'the attestation passed' an insufficient answer on SEV/SEV-ES.

Who can reach it

Malicious hypervisor. Affects SEV and SEV-ES; SEV-SNP addresses it with the reverse-map table enforcing page ownership and mapping.

What to do

**Not fixable on SEV or SEV-ES** - migrate confidential workloads to SEV-SNP, where the RMP enforces the guest-physical to system-physical mapping. Practically that means EPYC Milan (7003) or newer with SNP enabled in SBIOS and a VMM that launches SNP guests. If you are attesting SEV/SEV-ES guests today, understand that a passing attestation report does not establish the guest is running the code that was measured.

References