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

[Dave Hansen <dave.hansen@intel.com>]

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.

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