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;
Date:   Tue, 18 Jul 2023 17:35:19 +0100
From:   Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
To:     Paolo Bonzini <pbonzini@redhat.com>
Cc:     Luca Boccassi <bluca@debian.org>, Ard Biesheuvel <ardb@kernel.org>,
        Emanuele Giuseppe Esposito <eesposit@redhat.com>,
        x86@kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        lennart@poettering.net, Ingo Molnar <mingo@redhat.com>,
        Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "H. Peter Anvin" <hpa@zytor.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
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
Message-ID: <ZLa/R9tZ0hB0KOXj@redhat.com>
Reply-To: Daniel =?utf-8?B?UC4gQmVycmFuZ8Op?= <berrange@redhat.com>
References: <20230711154449.1378385-1-eesposit@redhat.com>
 <ZK/9MlTh435FP5Ji@gambale.home>
 <df7941b9-11ea-9abd-e070-4e9926aecdc3@redhat.com>
 <CAMw=ZnTSyeL4x1o_GVKNsZdCUe2D2H53quK-TSFhOkuONjC73A@mail.gmail.com>
 <CABgObfb_jGgs-yMSsHtHhEStFDp4f072LN7pW+3dSuVhAP87Ag@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CABgObfb_jGgs-yMSsHtHhEStFDp4f072LN7pW+3dSuVhAP87Ag@mail.gmail.com>
User-Agent: Mutt/2.2.9 (2022-11-12)
Precedence: bulk

On Tue, Jul 18, 2023 at 05:51:56PM +0200, Paolo Bonzini wrote:
> On Tue, Jul 18, 2023 at 4:03 PM Luca Boccassi <bluca@debian.org> wrote:
> > > So perhaps there could be some kind of protocol that would let a new
> > > kernel tell the bootloader "don't boot an older kernel than me in the
> > > future".  It could even be an extension to the SBAT spec itself.  I
> > > haven't really thought much about it, tbh.  However, I'm quite positive
> > > that a revocation index attached to the kernel image cannot really work
> > > as a concept, not even if it is managed by the distro.
> >
> > You are pretty much describing SBAT there. Except for the detail that
> > it can't be the component that can be compromised that tells you
> > whether it's compromised and you should trust it... A system's SBAT
> > policy is a single entity, managed centrally, and deployed everywhere.
> 
> Fine, so can the SBAT spec be extended to have some kind of version
> that is not a single number? If that is provided, Linux could have the
> mechanism to place the kernel version in the .sbat section. But I
> agree with Borislav, Greg and others that a single revocation index
> simply doesn't cut it.

In theory it could already be treated as being a version if you were
to just encode the 3 version number components into an integer.

There's a slight caveat that when parsing sbat shim currently appears
to store the generation number in a uint16, so the size is somewhat
limited. Probably still just enough bits to encode a kernel version,
though changing shim code to uint32 looks easy enough too.

Directly encoding the version number though has implications for
revokation wrt stable branches though. My impression is that the
generation number was intentionally separate from a version number,
so that people could backport particular fixes to a stable branch
and then declare it to be the same "generation" as the latest
devel branch, or other stable branches which also included the
equiv fixes.

Obviously that presumes that an old branch can be made secure by
selectively backporting patches. That is a view which is obviously
not universally accepted, especially in upstream context, as clearly
expressed in several mails in this thread. It is what distros would
typically claim to achieve though. I'm not sure it is possible to
satisfy both those differing views.

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 :|