On Thu, Mar 06, 2025 at 04:11:25AM +0000, Andrew Cooper wrote: > On 06/03/2025 3:15 am, Solar Designer wrote: > > 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? > > First of all, there's an equivalent change in Linux. > > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb2281fb05e50108ce95c43ab7e701ee564565c8
Oh, I had missed that, thanks! > [...] 3rd party repositories of microcode repositories ripped > out of firmware exist, there is a small but known usergroup who take > microcode from a 3rd party source. > > As of today, anyone can make an arbitrary malicious microcode that will > load on Zen1-4 CPUs. > > This issue wins points for spite, because the highest risk users are the > ones who were taking proactive steps to try and improve their security, > betting that AMD's patchloader crypto was sound. OK, so this is to protect legitimate sysadmins from loading malicious microcode inadvertently or via a supply chain attack. Makes sense. > 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 > In Xen we're working towards properly supporting UEFI Secure Boot. > We're not there yet (there's a lot of technical debt to overcome), hence > why this isn't a full-blown XSA. > > All of that said, it's also likely that there are a lot of vulnerable > but uncompromised systems. These measures in Xen and Linux are a > stopgap; a bit of extra defence in depth. They're certainly not perfect. OK. Thanks again, Alexander
