Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230712120002.GIZK6Vwga6DlJqdjEh@fat_crate.local>
 <ZK6hLZcuAH9jXKuL@redhat.com> <20230712132840.GKZK6qiK70m1O90jFL@fat_crate.local>
 <ZK6zdsIbnQFUmK69@redhat.com> <2023071200-unopposed-unbuckled-cde8@gregkh>
 <CAMw=ZnTVRaqRmtz+sDj7AeAS7xivSu+56UgKbzmuW9+K6TTx1A@mail.gmail.com>
 <2023071239-progress-molasses-3b3d@gregkh> <CAMw=ZnRheXk7W_r-32bGymbHKdXc7aKUpwGAOX+k7DJkN+DiCQ@mail.gmail.com>
 <2023071229-dusk-repacking-da3a@gregkh> <CAMw=ZnSmZTBs+bJsQ_Y2CVO8K3OTuHOZDKW4cbxKpGbo4Vgs7Q@mail.gmail.com>
 <20230712194202.GNZK8CCj4yacgFMgfB@fat_crate.local>
In-Reply-To: <20230712194202.GNZK8CCj4yacgFMgfB@fat_crate.local>
From:   Luca Boccassi <bluca@debian.org>
Date:   Wed, 12 Jul 2023 20:56:36 +0100
Message-ID: <CAMw=ZnSa-NqfbEd9vchEwHwdUujNAXo=gb3dfd=HDw4W37RNjQ@mail.gmail.com>
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
To:     Borislav Petkov <bp@alien8.de>
Cc:     Greg KH <gregkh@linuxfoundation.org>,
        =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@redhat.com>,
        Emanuele Giuseppe Esposito <eesposit@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, x86@kernel.org,
        Thomas Gleixner <tglx@linutronix.de>, lennart@poettering.net,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Alexander Potapenko <glider@google.com>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Vitaly Kuznetsov <vkuznets@redhat.com>,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, 12 Jul 2023 at 20:42, Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, Jul 12, 2023 at 08:35:14PM +0100, Luca Boccassi wrote:
> > No, all will not be fine, because stable branches exist, so it would
> > not be _one_ kernel version but N, with monotonically increasing
> > values of N. That doesn't work, and the reason for that are explained
> > in the protocol documentation that was linked in the initial mail.
>
> Lemme give Peter's example from earlier today:
>
> Bugfix A -> number 2
> Bugfix B -> number 3
>
> Tree backports only Bugfix B. Which number do you use?
>
> And so on and so on.

Everything < 3 is revoked _and_ the generation id in the stable branch
is _not_ bumped, because it's still vulnerable and so that branch is
effectively dead and unbootable on any system with secure boot
enabled. This is a revocation mechanism, not a bug tracking mechanism.
There's no mix-and-matching.

> Patch your own trees - this doesn't belong upstream.

Nah, it belongs in both places. Please read the documentation and
spend at least some time trying to understand the actual problem being
solved before commenting - or don't comment at all, that's fine too.