Message-ID: <87iksrhkv8.fsf@canonical.com>
Date: Wed, 13 Nov 2024 13:59:31 +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 Tue, 2024-11-12 at 07:51:38 -0800, 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".

My point is that if a given microcode contains only functional updates,
then if you are *not* using it you do not have a security
vulnerability. If however the specified microcode revision fixes a known
security issue then yes I agree, there is a vulnerability and if you are
not using this microcode revision you are vulnerable to it. It is really
the distinction between a microcode update that is purely for functional
issues compared to one that is for security issues as well.

>
>> 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.

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.

>
> 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.
>

But just because something is bad that doesn't mean it is a security
vulnerability. One option could be to taint the kernel in this case
instead.

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

So I suggest instead if you really want to flag old microcode as an
issue you could taint it as such since the description of tainted is

> The kernel will mark itself as ‘tainted’ when something occurs that
> might be relevant later when investigating problems

which feels like exactly the kind of semantics you describe above.

Then if you also want to surface old microcode that also is missing
security fixes you could then use your new proposed mechanism.

Powered by blists - more mailing lists