AMD Zen microcode patch loader (CPU ROM signature verification): MULTI-TENANT ISOLATION: The CPU ROM's microcode patch

Impact

MULTI-TENANT ISOLATION: The CPU ROM's microcode patch loader verified patch signatures using AES-CMAC with a published example key, so an attacker with local administrator privilege can sign and load their own microcode onto Zen 1 through Zen 4 CPUs. Loading arbitrary microcode means redefining what x86 instructions do - the attacker can make RDRAND return a constant, disable checks, or backdoor the CPU beneath every layer of software. For a confidential-computing operator this is the ballgame: SEV-SNP's entire guarantee rests on the CPU behaving as specified, so a host administrator can now read and tamper with any SEV-SNP guest's memory while the attestation report still looks clean. Google's security team demonstrated the full chain.

Who can reach it

Local, requires ring-0 / host administrator privilege. Not remote, and not reachable from a tenant container. But 'host administrator' is exactly the adversary SEV-SNP exists to exclude, which is why a local-admin bug is a confidential-computing catastrophe rather than a routine escalation. Persistence note: microcode does not survive a power cycle, so an attacker must reload it each boot - which also means a cold boot clears an implant.

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. Specifically: AMD shipped fixed microcode plus an updated ASP bootloader in AGESA (December 2024 / released publicly February 2025). Zen 1-4 EPYC and Ryzen are affected; Zen 5 is not. The critical operator step people skip is the attestation side - after the TCB bump, refresh VCEK certs and require tenants to pin the new minimum TCB, otherwise you are patched but still accepting attestations that would have been valid on a backdoored host.

References