Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

[Paolo Bonzini]

On Tue, Jul 18, 2023 at 6:35 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> 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

> 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/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
>