Re: Xen Security Notice 2 (CVE-2024-35347) AMD CPU Microcode Signature Verification Vulnerability

[Andrew Cooper <andrew.cooper3 () citrix com>]

On 06/03/2025 4:48 am, Solar Designer wrote:
> > Under Host UEFI Secure Boot, there is a security boundary between kernel
> > code and root.  Part of the requirement is "no unsigned code running
> > privileged", and while this is technically a grey area (the malicious
> > blob is signed; it's just not signed by AMD), it's also easy to argue
> > that root definitely shouldn't be able to load a malicious microcode,
> > just like it shouldn't be able to swap out the kernel with an unsigned
> > one and reboot.
> Yes, but can't Xen's and the kernel's new protections be bypassed by MSR
> access via /dev/cpu/*/msr?  The AMD microcode loader released by Google
> now doesn't appear to require more than that:
>
> https://github.com/google/security-research/blob/master/pocs/cpus/entrysign/zentool/loader.c

For Linux, /dev/cpu/*/msr isn't available when lockdown mode is active.

For Xen, guests can't load microcode at all (writes to the relevant MSRs
are simply swallowed).  Actually loading microcode is done via
hypercall, restricted to privileged domains, and digest checking can't
be disabled without a reboot (or a livepatch, which in a UEFI-SB model
needs to itself be signed).


Answering Bastian's question from the other fork of this thread (sorry,
I'm not CC'd).

Maintaining the hash list is a concern, but in the immediate term, the
relevant maintainers in Linux and Xen.

Something better is being worked on, but there are challenges beyond
just technical ones.

~Andrew