AMD SEV-SNP migration agent (report ID assignment): MULTI-TENANT ISOLATION: An imported SEV-SNP guest is not assigned

Impact

MULTI-TENANT ISOLATION: An imported SEV-SNP guest is not assigned a fresh report ID, so the guest can be tricked into trusting a dishonest Migration Agent. Live migration is the moment a confidential VM is most exposed - it has to hand its state to something - and this lets a malicious host present an MA the guest will accept. The guest then migrates its secrets into an attacker-controlled destination believing it is talking to a legitimate peer.

Who can reach it

Requires a malicious or compromised hypervisor driving guest migration. Only exercised if you actually use SEV-SNP live migration.

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. If you do not offer live migration for confidential VMs, the path is not exercised and this can sit in the normal patch queue. If you do, it is a top-of-queue item, and worth reviewing whether migration should be disabled for confidential tenants until the fleet is patched.

References