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

[Alex Murray]

On Wed, 2024-11-13 at 08:00:26 -0800, Dave Hansen wrote:

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

The only other data point then to mention is that all the major distros
(Debian[1], Ubuntu[2] and Fedora[3]) are still only shipping the previous
security update release (20240910) in their stable releases - *not* the
more recent release with the functional updates in 20241029 - in which
case anyone running a current stable release would then show as being
"vulnerable". I can't speak for the other distros, but for Ubuntu we
generally only ship things which are called out as specific security
fixes in our security updates *and* we generally prioritise security
updates over bug fixes (which these 'functional' updates appear be
rather than fixing actual exploitable security issues).

> So I'm leaning toward setting:
>
> 	TAINT_CPU_OUT_OF_SPEC
> plus
> 	X86_BUG_OLD_MICROCODE
>
> and calling it a day.

Does this mean you are thinking of dropping the userspace entry in the
cpu vulnerablities sysfs tree? If so then I am not so concerned, since
my primary concern is having something which looks scary to
users/sysadmins ("your CPU has an unpatched vulnerablity") which they
can't do anything about since their distribution has a different
definition of what counts as a security update compared to the upstream
kernel maintainers. If the sysfs entry is dropped then this is not so
visible to end-users and hence there is less panic.


[1] https://packages.debian.org/search?keywords=intel-microcode
[2] https://launchpad.net/ubuntu/+source/intel-microcode
[3] https://packages.fedoraproject.org/pkgs/microcode_ctl/microcode_ctl/fedora-41.html