Message-ID: <87serpgcrr.fsf@canonical.com>
Date: Mon, 18 Nov 2024 19:05:36 +1030
From: Alex Murray <alex.murray@...onical.com>
To: Dave Hansen <dave.hansen@...el.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 Wed, 2024-11-13 at 16:37:31 -0800, Dave Hansen wrote:
> 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.

Again, I can't speak for other distros but for Ubuntu see my comment
above re prioritising security vs functional updates.

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

For calling out old microcode as a vulnerability, yes I would prefer
that only releases which your colleagues state as fixing security issues
get included. However, for the tainted case, anything older than the
current release would make sense. In which case you would have to
maintain two different revision IDs per MCU - one which is the latest,
and the other which is the latest with a security fix for a given
platform. From my experience though it is a more rare occasion that a
new upstream microcode release does not contain some security fixes. So
perhaps this distinction will be mostly irrelevant in practice assuming
most all MCU releases contain a fix for some security issue.

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

Yep I agree, end-users should always be the primary concern especially
for new user visible things like new entries in the vulnerabilities
sysfs tree. Also I am not averse to calling out the situation of running
an out-of-date microcode *which has known security issues* as a
vulnerability, I think providing more data to users to help them make
the best assessment of any given risk is always a good thing, but we
just need to be mindful to do it in a way that is hopefully actionable
as well.

Powered by blists - more mailing lists