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: <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> <ZLa/R9tZ0hB0KOXj@redhat.com>
In-Reply-To: <ZLa/R9tZ0hB0KOXj@redhat.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
Date:   Wed, 19 Jul 2023 15:21:39 +0200
Message-ID: <CABgObfZjVrGOSn8iuFeUBOv3NAU_HB-6vtUTCRcSPW=Guua1jQ@mail.gmail.com>
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage
To:     =?UTF-8?Q?Daniel_P=2E_Berrang=C3=A9?= <berrange@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
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Tue, Jul 18, 2023 at 6:35=E2=80=AFPM Daniel P. Berrang=C3=A9 <berrange@r=
edhat.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/k=
oji/packageinfo?packageID=3D8

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

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

Paolo

> 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/dberran=
ge :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.c=
om :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberran=
ge :|
>