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: <4dfb0169-ac37-4c93-8c3b-e8e21a73d8c8@suse.com>
Date: Wed, 13 Nov 2024 11:28:00 +0200
From: Nikolay Borisov <nik.borisov@...e.com>
To: Dave Hansen <dave.hansen@...el.com>,
 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 12.11.24 г. 17:51 ч., Dave Hansen wrote:
> On 11/11/24 22:37, Alex Murray wrote:
>>> == Microcode Revision Discussion ==
>>>
>>> The microcode versions in the table were generated from the Intel
>>> microcode git repo:
>>>
>>>   	29f82f7429c ("microcode-20241029 Release")
>>
>> This upstream microcode release only contained an update for a
>> functional issue[1] - not any fixes for security issues. So it would not
>> really be correct to say a machine running the previous microcode
>> revision is vulnerable.
> 
> There are literally two things this patch "says".  One is in userspace
> and can be literally read as:
> 
> 	/sys/devices/system/cpu/vulnerabilities/old_microcode
> 
> "You are vulnerable to old CPU microcode".
> 
> The other is in the code: X86_BUG_OLD_MICROCODE.  Which can literally be
> read to say "you have a CPU bug called 'old microcode'. (Oh, and I guess
> this comes out in /proc/cpuinfo too).
> 
> If you think this is confusing, we can document our way out of it or
> revise the changelog.  But we kinda get to define what the file and the
> X86_BUG mean in the first place.
> 
> I don't really see how it's possible to argue that they're "incorrect".
> 
>> As such, should the table of microcode revisions only be generated
>> from the upstream microcode releases that contain fixes for security
>> issues?
> 
> 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.
> 
> Second, running kernels with functional issues is *BAD*.  As a kernel
> policy, we don't want users running with old microcode. Security bugs
> only hurt our users but functional bugs hurt the kernel too because
> users blame the kernel when they hit them and kernel developers spend
> time chasing those issues down.

<Perhaps offtopic>

Probably the same reasoning can be applied here as for the CVEs - since 
the kernel (microcode) is a very fundamental piece of software, almost 
any issue can be treated as a security one (at least judging from the 
influx of automatically generated CVEs). By the same token we can assume 
that microcode always fixes a critical issue :)

</Perhaps offtopic>

> 
> So I guess it boils down to: First, should we tell users when their
> microcode is old?  If so, how should we do it?
>