[<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
Powered by blists - more mailing lists