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

[Nikolay Borisov]

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?