linux-kernel - Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

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]

Date:   Mon, 17 Jul 2023 12:47:21 +0100
From:   Daniel P. Berrangé <berrange@...hat.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Greg KH <gregkh@...uxfoundation.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 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.

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.

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.

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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|