Message-ID: <2023071717-undead-amiable-3427@gregkh>
Date:   Mon, 17 Jul 2023 16:10:44 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Daniel P. Berrangé <berrange@...hat.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Luca Boccassi <bluca@...ian.org>,
        Borislav Petkov <bp@...en8.de>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>, lennart@...ttering.net,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Alexander Potapenko <glider@...gle.com>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

On Mon, Jul 17, 2023 at 12:47:21PM +0100, Daniel P. Berrangé wrote:
> On Mon, Jul 17, 2023 at 01:06:31PM +0200, Peter Zijlstra wrote:
> > On Mon, Jul 17, 2023 at 10:22:51AM +0100, Daniel P. Berrangé wrote:
> > > I'm not aware of any kernel CVEs since that point in time that
> > > would have implied SBAT changes, but admittedly I've not paid
> > > close enough attention to be entirely confident. Is going back
> > > through 2 years of kernel CVEs (to the point where SBAT was
> > > invented) a long enough timeframe to satisfy this request for
> > > info on the frequency of changes ?
> > 
> > Many *MANY* security bugs never get a CVE. CVE is meaningless when it
> > comes to kernel bugs. Why does it make sense to review CVEs ?
> 
> Yes, I know many security bugs gets fixed without a CVE being
> assigned, but in the context of the question that doesn't
> matter.

"most" security bugs never get a CVE, and by "most" I mean "almost all".

> The SBAT version number will be incremented in response to an
> identified security bug. Even if upstream has not assigned a
> CVE to an issue, downstream vendors are likely to have done
> so *if* they identified the security issue.

So this is yet-another-pointless number that only would kick in if
someone took the time to fill out a form and bump the number because
they either wanted to pad their CV, or they wanted to grease the wheels
of a broken engineering process.

This is going to ensure that actual bugs that do fix issues that should
have "bumped" this number, never cause it to actually be changed, so
people will have a total false sense of security, which is EXACTLY what
is wrong with CVEs today (among many other things as mentionted.)

If you do this this way, you will be signalling to people the exact
oposite thing you want to signal, namely "don't update this kernel
because no real problem has been found in it", which is NOT the real
thing to be saying as we have documented numberous times in the past.

> If neither upstream, nor downstream, publically identified a
> fix as a security issue, then by extension they would also
> not have identified a need to change to the SBAT version info
> either.

So all the known security bugs that we fix on a weekly basis and get
merged into the kernel trees and stable updates and pushed out to
people's machines would never actually bump this number, which means
that this number is meaningless.

Great, so we don't need it at all then :)

> Thus looking at publically identified security issues via
> CVEs is a reasonable proxy to guage how many times SBAT
> would have been incremented, which is what Greg asked for.

Again, not at all given my previous responses.  If you actually think
that CVEs represent ANYTHING regarding security fixes or not for the
kernel, I have a bridge to sell you :)

thanks,

greg k-h

Powered by blists - more mailing lists