Improper signature verification in AMD CPU ROM microcode patch loader may allow an attacker with local administrator privilege to load malicious CPU microcode resulting in loss of confidentiality and integrity of a confidential guest running under AMD SEV-SNP.
On Wed, Mar 05, 2025 at 07:11:23PM +0000, Andrew Cooper wrote: See:
https://bughunters.google.com/blog/5424842357473280/zen-and-the-art-of-microcode-hacking https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7033.html
Right now there are four known but (reasonably) benign microcodes from a non-AMD source. However, there is a tool to sign arbitrary microcode.
In Xen, we've provided a stopgap mitigation to perform extra checks on microcode load on affected CPU families. This is a SHA2 digest check against hashes with believed-good provenance. This is staging only for now, in case it is overly disruptive.
This will not protect against an already-compromised platform, but it will prevent an uncompromised system becoming compromised via Xen's microcode loading capabilities. Thank you, Andrew!
Maybe you can also clarify what Xen's threat model is here, and how this mitigation fits into it?
Specifically, what are "Xen's microcode loading capabilities" and are they in any way more exposed than the host system's root account? Even with Xen's mitigation above, host root can still load microcode without Xen involvement, right? Unless you block (at least) MSR access and kernel module loading?
Also, by "uncompromised system", do you specifically mean uncompromised at microcode level? If the threat is from a Xen administrator, then perhaps that's a partial security compromise already, just not yet extended to microcode.
These things may be obvious to someone more familiar with Xen, but your message and answers to the above are also interesting to the rest of us. On affected systems, the only complete fix is a firmware update. This is a very firmly recommended course of action.
Sincerely,
~Andrew, on behalf of the Xen Security Team. Alexander