Message-ID: <CAMw=ZnR6DBPxwdbP9jJRLzkryaoz++Nkxx5KV-3RdHL5PXKoqQ@mail.gmail.com>
Date:   Wed, 19 Jul 2023 14:34:34 +0100
From:   Luca Boccassi <bluca@...ian.org>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Daniel P. Berrangé <berrange@...hat.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
        lennart@...ttering.net, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.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 Wed, 19 Jul 2023 at 14:22, Paolo Bonzini <pbonzini@...hat.com> wrote:
>
> On Tue, Jul 18, 2023 at 6:35 PM Daniel P. Berrangé <berrange@...hat.com> wrote:
> > 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.
>
> Encoding a kernel version needs a uint32 if you want to make it human
> readable; you need at least 10^6 (9.99.999) for the upstream version.
>
> However a SBAT policy based on kernel versions will not allow stable
> versions, so it's basically unusable.
>
> One possibility would be to encode the major and minor versions as
> different products, so a Fedora package for Linux 6.1.137 would have:
>
> linux.6,1,Linux,https://kernel.org/
> linux.6.1,137,Linux 6.1.y,6.1.137,https://kernel.org/
> linux.6.1.fc38,302,Fedora,6.1.137-302.fc38,https://koji.fedoraproject.org/koji/packageinfo?packageID=8
>
> where old kernel versions can be "prohibited" without consuming too
> much space in the policy, for example
>
> linux.5,255       # block all 5.x kernels.
> linux.6.1,138    # oh no, 6.1.137 had a *really* bad vulnerability
>
> The questions then are
>
> 1) if this satisfies the requirements
>
> 2) if upstream people accept to expose the version in this format in
> the upstream kernel

That doesn't work, because it requires a new line for each new
release, which means the sbat revocation variable and payload have
unbounded growth, and the number one goal of this mechanism was to
avoid exactly that. That's why it's a generation id, and that's why
it's per-product.

Once again: this is not some generic, multi-purpose tracking. This is
not for human consumption. This is not a substitute for a version, or
a bug tracker, or whatever else. This does not inform users of
anything.
This is a machine-targeted mechanism to allow centrally-managed
revocations for the UEFI 3rd party CA + Shim flow in a way that works
for the constrained EFI environment w.r.t size, wear and tear, in
substitution of DBX which is not fit for this purpose.

> > 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.
>
> Right, but that also requires a central authority that makes up these
> revocation indices. This is unlikely to happen for Linux. :)

It will happen, the only question is how painful it is going to be to
maintain it. The revocation payload is unique and global, and it could
not be otherwise. Just like DBX is published centrally, and just like
Shim signing is done centrally.

Powered by blists - more mailing lists