AMD CPU microcode patch loading - improper cleanup: MULTI-TENANT ISOLATION: Improper cleanup during microcode patch

Impact

MULTI-TENANT ISOLATION: Improper cleanup during microcode patch loading gives a local administrator another route to load malicious CPU microcode, costing integrity of x86 instruction execution itself. This is the same category of failure as EntrySign and lands in the same place: the CPU can be made to lie, and everything built on top of it - SEV-SNP guest isolation included - inherits the lie.

Who can reach it

Local, administrator privilege. Reboot clears a loaded implant, but the attacker who has admin can simply reload it every boot.

What to do

Fixed by an AMD microcode patch. Two delivery routes, and the difference matters: the linux-firmware amd-ucode blobs load early at boot (initramfs) and need only a reboot, while the durable fix is the microcode embedded in the OEM SBIOS/AGESA package, which carries the usual one-to-six-month OEM lag and a full power cycle. **For confidential computing you need the SBIOS route**: microcode late-loaded by the OS is not part of what SEV-SNP attests, so a guest checking the attestation report cannot tell the fix is present. AMD does not support late-loading microcode on a running EPYC host - treat this as reboot-required. After patching, expect the reported TCB version to change and plan the VCEK certificate refresh accordingly.

References