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]

Message-ID: <2023071700-blot-angular-cf6f@gregkh>
Date:   Mon, 17 Jul 2023 16:11:36 +0200
From:   Greg KH <gregkh@...uxfoundation.org>
To:     Luca Boccassi <bluca@...ian.org>
Cc:     Daniel P. Berrangé <berrange@...hat.com>,
        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:12:18PM +0100, Luca Boccassi wrote:
> On Mon, 17 Jul 2023 at 10:23, Daniel P. Berrangé <berrange@...hat.com> wrote:
> >
> > On Sun, Jul 16, 2023 at 08:28:10PM +0200, Greg KH wrote:
> > > On Sun, Jul 16, 2023 at 06:41:04PM +0100, Luca Boccassi wrote:
> > > > On Sat, 15 Jul 2023 at 07:52, Greg KH <gregkh@...uxfoundation.org> wrote:
> > > > >
> > > > > If you are not willing to take the time to determine how this proposed
> > > > > change will affect the kernel developers and infrastructure by doing
> > > > > some modeling based on our past history, then we have no reason to even
> > > > > consider accepting this change as you are stating that you have no idea
> > > > > how it will affect us.
> > > >
> > > > There's no need for that to tell you how this will affect you: it will
> > > > not. Every now and then you'll receive a one-liner patch to apply.
> > > > What's so terrible about that?
> >
> > I think that's not entirely accurate, as this *will* have an impact on
> > anyone involved in backporting fixes for the kernel stable trees, when
> > they need to resolve conflicts on the SBAT file. It shouldn't have a
> > big impact, but we should be honest that it will be a non-zero impact.
> >
> > Lets say mainline branch has had 2 security vulnerabilities A and B,
> > each of which was associated with an increment of the SBAT version
> > number. The first flaw A changed SBAT from 7 to 8,and then the second
> > flaw B changed SBAT from 8 to 9.
> >
> > If someone wants to backport the fix for bug "B" they will get a
> > conflict on the SBAT file when cherry-picking the patch. When that
> > happens they must decide:
> >
> >   * It is acceptable to ignore issue A, because it didn't affect
> >     that branch. The conflict is resolved by having the backported
> >     patch increase SBAT version from 7 to 9 directly.
> >
> >   * It is required to first backport issue A, because that also
> >     affects that branch. The conflict is resolved by first backporting
> >     the code fix & SBAT change for A, and then backporting the code
> >     fix and SBAT change for B. SBAT changes from 7 to 8 to 9 just
> >     like on master.
> >
> > IOW whomever is doing backport patches for stable needs to understand
> > the semantics of SBAT and how to resolve conflicts on it. If they get
> > this wrong, then it breaks the protection offered by SBAT, which would
> > then require a 3rd SBAT change to fix the mistake.
> >
> > This likely means that stable tree maintainers themselves need to
> > understand the SBAT change rules, so they can review conflict resolution
> > for any proposed changes, to sanity check what is being proposed.
> 
> This can be solved by just not changing the generation id in the same
> patch that fixes a bug, but as the last step in a series, which
> doesn't add the cc: stable nor the other tags. If we want to bump the
> generation id in a stable branch, we'll then have to send an
> appropriately crafted patch targeted at the right place. That way even
> if the fixes get backported, there is no additional burden on any
> kernel maintainer.

Who exactly will be "we" in this process and who will be funding this
effort to ensure that they keep doing this work for the next 20+ years?

thanks,

greg k-h