AMD CPU microcode - RDRAND entropy after patch load: MULTI-TENANT ISOLATION: Incomplete cleanup after loading

Impact

MULTI-TENANT ISOLATION: Incomplete cleanup after loading a microcode patch degrades the entropy of RDRAND, so a privileged attacker can weaken the randomness that SEV-SNP guests draw on. Guests that seed keys or nonces from RDRAND get predictable material, which quietly breaks their crypto without breaking anything visible. The score is low; the failure mode - silent, undetectable, affects key generation - is not.

Who can reach it

Local, privileged attacker who can trigger microcode patch loading. Effect lands on SEV-SNP guests on that host.

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. Guests that generated long-lived keys on an affected host should rotate them; patching stops future weak output but does nothing about keys already derived from degraded entropy.

References