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: <ZLVyvAXwtemx1I6p@redhat.com>
Date:   Mon, 17 Jul 2023 17:56:28 +0100
From:   Daniel P. Berrangé <berrange@...hat.com>
To:     James Bottomley <James.Bottomley@...senpartnership.com>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        x86@...nel.org, Thomas Gleixner <tglx@...utronix.de>,
        bluca@...ian.org, 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, linux-efi@...r.kernel.org
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

On Mon, Jul 17, 2023 at 12:08:26PM -0400, James Bottomley wrote:
> On Thu, 2023-07-13 at 15:52 +0200, Ard Biesheuvel wrote:
> > (add linux-efi@ cc)
>
> Thanks for that, since this is really EFI related rather than x86.

snip

> The problem, as I see it, is if the distros give the kernel an .sbat
> section, that means any vanilla kernel that's built by a user and
> signed by their key now won't work (even if their key is in MoK)
> because it won't have an sbat section ... and the sbat mechanism is
> component specific, not key specific, so the signer has no choice but
> to adopt it.

AFAICT, that problem only exists for binaries directly invoked
from shim. So that would be a problem for the boot loader (grub),
or a kernel image being booted directly without a bootloader
present.

For kernel binaries invoked indirectly by the boot loader, the
use of SBAT is currently optional. ie missing SBAT record would
be treated as success.

This was a pragmatic way to introduce SBAT support as it only
impacted grub at that time.

Once a distro starts adding SBAT to their kenrels too though, we
can forsee that they would like to enforce SBAT for the whole
boot chain, to prevent rollback to previously signed binaries
that lacked SBAT info.

This policy could be enforced per key though. eg require SBAT
for anything verified against the vendor key that's compiled into
shim, but not require SBAT for binaries verified with the MoK
entries.

The user specific MoK entries don't have such a compelling use
case for SBAT, since if they need to revoke old binaries, the
end users always have the easy fallback option of just rotating
their signing keys and switching out the enrolled key in MoK.

The choice of whether to mandate SBAT for binaries signed with
a MoK entry, could be set by the end user themselves at the time
their enroll their signing cert in the MoK DB.

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