Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250306061351.GA7019@openwall.com>
Date: Thu, 6 Mar 2025 07:13:51 +0100
From: Solar Designer <solar@...nwall.com>
To: Bastian Blank <bblank@...nkmo.de>, 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 06:50:13AM +0100, Bastian Blank wrote:
> On Thu, Mar 06, 2025 at 05:48:56AM +0100, Solar Designer wrote:
> > > 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!
> 
> Who is expected to maintain this list of hashes?  Because this sounds
> like a huge maintenance hog, as this will now block any security updates
> of the microcode.

Per my skimming of the Linux patch above, need_sha_check() _partially_
addresses this concern by only requiring hashes for new microcode when
the currently loaded microcode is below certain revisions (perhaps those
where AMD has fixed this issue).  So it appears it won't be possible to
load some future microcode off a vulnerable microcode right away, but it
should be possible to do the same in two steps - load the current fixed
version first, then load whatever future version.  An issue is that
Linux distros' userland packages and generated initramfs images are not
prepared to use such two-step process, so your concern seems valid.

I hope someone corrects me if I misunderstood any of this.

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.