Message-ID: <CAMw=ZnTOgGcQ70E57H1GEr9yZVG-FVHZZ69JYMFqvsO9mgxdDg@mail.gmail.com>
Date:   Mon, 17 Jul 2023 12:12:18 +0100
From:   Luca Boccassi <bluca@...ian.org>
To:     Daniel P. Berrangé <berrange@...hat.com>
Cc:     Greg KH <gregkh@...uxfoundation.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, 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.

Powered by blists - more mailing lists