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

[Nikolay Borisov <nik.borisov@suse.com>]

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