linux-kernel - Re: [RFC][PATCH] x86/cpu/bugs: Consider having old Intel microcode to be a vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87h68avg81.fsf@canonical.com>
Date: Thu, 14 Nov 2024 10:28:22 +1030
From: Alex Murray <alex.murray@...onical.com>
To: Dave Hansen <dave.hansen@...el.com>, dave.hansen@...ux.intel.com
Cc: bp@...en8.de, linux-kernel@...r.kernel.org, tglx@...utronix.de,
 x86@...nel.org
Subject: Re: [RFC][PATCH] x86/cpu/bugs: Consider having old Intel microcode
 to be a vulnerability

On Wed, 2024-11-13 at 08:00:26 -0800, Dave Hansen wrote:

> While I applaud your trust in my employer, I don't see quite as bright
> of a line between security and functional problems.
>
> Here's the bottom line: I agree that setting a taint flag for old
> microcode seems like a good idea. But I also think that there's enough
> of a "vulnerability" (security or otherwise) to justify placing
> "old_microcode" alongside the CPU security vulnerabilities that have
> known exploits.
>
> I'm lazy and don't want to read and filter the microcode changelogs.  I
> also don't want to have to trust my colleagues to precisely agree on
> where that line is between a security and functional problem.
>

The only other data point then to mention is that all the major distros
(Debian[1], Ubuntu[2] and Fedora[3]) are still only shipping the previous
security update release (20240910) in their stable releases - *not* the
more recent release with the functional updates in 20241029 - in which
case anyone running a current stable release would then show as being
"vulnerable". I can't speak for the other distros, but for Ubuntu we
generally only ship things which are called out as specific security
fixes in our security updates *and* we generally prioritise security
updates over bug fixes (which these 'functional' updates appear be
rather than fixing actual exploitable security issues).

> So I'm leaning toward setting:
>
> 	TAINT_CPU_OUT_OF_SPEC
> plus
> 	X86_BUG_OLD_MICROCODE
>
> and calling it a day.

Does this mean you are thinking of dropping the userspace entry in the
cpu vulnerablities sysfs tree? If so then I am not so concerned, since
my primary concern is having something which looks scary to
users/sysadmins ("your CPU has an unpatched vulnerablity") which they
can't do anything about since their distribution has a different
definition of what counts as a security update compared to the upstream
kernel maintainers. If the sysfs entry is dropped then this is not so
visible to end-users and hence there is less panic.

[1] https://packages.debian.org/search?keywords=intel-microcode
[2] https://launchpad.net/ubuntu/+source/intel-microcode
[3] https://packages.fedoraproject.org/pkgs/microcode_ctl/microcode_ctl/fedora-41.html