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

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

On 11/12/24 19:29, Alex Murray wrote:
>> 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.

While I applaud your trust in my employer, I don't see quite as bright
of a line between security and functional problems.

Here's the bottom line: I agree that setting a taint flag for old
microcode seems like a good idea. But I also think that there's enough
of a "vulnerability" (security or otherwise) to justify placing
"old_microcode" alongside the CPU security vulnerabilities that have
known exploits.

I'm lazy and don't want to read and filter the microcode changelogs.  I
also don't want to have to trust my colleagues to precisely agree on
where that line is between a security and functional problem.

So I'm leaning toward setting:

	TAINT_CPU_OUT_OF_SPEC
plus
	X86_BUG_OLD_MICROCODE

and calling it a day.