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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CABgObfZjVrGOSn8iuFeUBOv3NAU_HB-6vtUTCRcSPW=Guua1jQ@mail.gmail.com>
Date:   Wed, 19 Jul 2023 15:21:39 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Daniel P. Berrangé <berrange@...hat.com>
Cc:     Luca Boccassi <bluca@...ian.org>, 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 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

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