[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <b21e9116-4108-4d52-b3b0-8c1e96486888@citrix.com>
Date: Thu, 6 Mar 2025 04:11:25 +0000
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Solar Designer <solar@...nwall.com>, oss-security@...ts.openwall.com
Subject: Re: Xen Security Notice 2 (CVE-2024-35347) AMD CPU
Microcode Signature Verification Vulnerability
On 06/03/2025 3:15 am, Solar Designer wrote:
> 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?
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
Owing to AMD either having 0 OS-loading support (client), and/or
sluggish firmware schedules (SinkClose / CVE-2023-31315 was especially
bad), and that 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.
While AMD has, to the best of my knowledge, done firmware updates for
all impacted systems, plenty of the older ones are out of support with
their OEM and will never get this fix.
> Also, by "uncompromised system", do you specifically mean uncompromised
> at microcode level?
Yes. Compromised microcode can, for example, backdoor the SKINIT
instruction and/or and forge measurements in the TPM, as microcode is
within the trust boundary for such technologies.
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.
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.
~Andrew
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.
