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: <c2f451e0f8d72cf3183aff9cbaf23f135fc7b495.camel@HansenPartnership.com>
Date:   Fri, 21 Jul 2023 07:24:28 -0400
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Luca Boccassi <bluca@...ian.org>,
        Eric Snowberg <eric.snowberg@...cle.com>
Cc:     Ard Biesheuvel <ardb@...nel.org>,
        "Daniel P." Berrangé <berrange@...hat.com>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "lennart@...ttering.net" <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>,
        open list <linux-kernel@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
        Jarkko Sakkinen <jarkko@...nel.org>
Subject: Re: [RFC PATCH v2] x86/boot: add .sbat section to the bzImage

On Fri, 2023-07-21 at 09:55 +0100, Luca Boccassi wrote:
> On Fri, 21 Jul 2023 at 02:49, Eric Snowberg
> <eric.snowberg@...cle.com> wrote:
> > > On Jul 20, 2023, at 1:16 PM, Luca Boccassi <bluca@...ian.org>
> > > wrote:
> > > On Thu, 20 Jul 2023 at 18:11, Eric Snowberg
> > > <eric.snowberg@...cle.com> wrote:
[...]
> > > > I agree with James in the previous thread;  adding the SBAT
> > > > section to the kernel should be handled by the signing tools.
> > > > It really doesn't need to be included in the mainline kernel
> > > > code. I also agree with the sentiment that mainline and the
> > > > stable branches should not have SBAT versions attached
> > > > to them. These are things distros should be responsible for
> > > > including in their kernel if they want to have SBAT support.
> > > 
> > > Why would 'signing tools' handle that? It's just a text-based PE
> > > section, it doesn't require access to private key materials to be
> > > handled, nor it has any relationship with signing.
> > 
> > There is a relationship, the sbat information within the signed
> > file can be used for revocation in lieu of revoking the hash or
> > signing certificate at a later time.
> 
> No, it is completely disjoint. In fact, the kernel doesn't even have
> to be signed at all, but it still _must_ have a .sbat section when it
> is used in a UKI.

Just a minute, this is wrong.  I was talking to Peter after all of this
blew up about how we handle signed kernels with no sbat (since we need
that still to work for developers who sign their own kernels).  I
thought he was planning to require an sbat section for all EFI
binaries, but he says that's not true.  The current way shim does the
sbat check is that if the section doesn't exist the binary is processed
as having an empty sbat section (i.e. no sbat level checking will be
done because there's no named sbat level for anything and it will just
work) and they're planning to keep it that way so that a signed but no
sbat kernel will always "just work" without any special key handling in
shim.  So if we're planning to keep this no-sbat case in discrete
kernels, even when the shim verifier checks sbat, the UKI kernel will
need to work for this case as well.

James

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ