[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250306044856.GA6417@openwall.com>
Date: Thu, 6 Mar 2025 05:48:56 +0100
From: Solar Designer <solar@...nwall.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Xen Security Notice 2 (CVE-2024-35347) AMD CPU Microcode Signature Verification Vulnerability
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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
