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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <844f58da-638f-4a91-88e7-f66f7fcefe51@intel.com>
Date: Wed, 13 Nov 2024 16:37:31 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Alex Murray <alex.murray@...onical.com>, dave.hansen@...ux.intel.com
Cc: bp@...en8.de, linux-kernel@...r.kernel.org, tglx@...utronix.de,
 x86@...nel.org
Subject: Re: [RFC][PATCH] x86/cpu/bugs: Consider having old Intel microcode to
 be a vulnerability

On 11/13/24 15:58, Alex Murray wrote:
...
> 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).

That's a very important data point. Thanks for that.

Like I said in the original changelog, I'm open to relaxing things to
define old to allow folks to be a release or two behind. But I'd want to
hear a lot more about _why_ the distros lag. I'd probably also have some
chats to see what other folks at Intel think about it.

So what would you propose the rules be?  Are you suggesting that we go
through the microcode changelogs for each CPU for each release and only
update the "old" revisions for security issues?  If there were only
functional issues fixed for, say, 2 years, on a CPU would the "old"
version get updated?

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

No, I plan to keep X86_BUG_OLD_MICROCODE and the corresponding sysfs entry.

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

Right, we don't want to unnecessarily scare anyone.

But if a distro is being too slow in getting microcode out, then it
would be good to inform users about known functional or security gaps
they're exposed to.

That's the thing we need to focus on.  Not: "Can users do anything about
it?" Rather: "What's best for the users?"