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: <7fc07eff-b4a1-4f8d-a9de-dba057d5c9c6@intel.com>
Date: Wed, 13 Nov 2024 08:00:26 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Alex Murray <alex.murray@...onical.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 11/12/24 19:29, Alex Murray wrote:
>> No, I don't think so. First, I honestly don't want to have this
>> discussion every three months where folks can argue about whether a
>> given microcode release is functional or security.  Or, even worse,
>> which individual microcode *image* is which.
> I don't think there is an argument here - releases at
> https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files
> clearly say if they contain Security updates or updates for functional
> issues - so if a release like the previous 20241029 one only contains an
> update for functional issues it should not be treated as a security
> issue if a system is not running it.

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.

So I'm leaning toward setting:

	TAINT_CPU_OUT_OF_SPEC
plus
	X86_BUG_OLD_MICROCODE

and calling it a day.