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: <d67ac07c71097a4c97c8792c7c1fac9f4d5850dd.camel@HansenPartnership.com>
Date:   Thu, 20 Jul 2023 13:07:34 -0400
From:   James Bottomley <James.Bottomley@...senPartnership.com>
To:     Eric Snowberg <eric.snowberg@...cle.com>,
        Ard Biesheuvel <ardb@...nel.org>
Cc:     "Daniel P." Berrangé <berrange@...hat.com>,
        Emanuele Giuseppe Esposito <eesposit@...hat.com>,
        "x86@...nel.org" <x86@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "bluca@...ian.org" <bluca@...ian.org>,
        "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 Thu, 2023-07-20 at 16:46 +0000, Eric Snowberg wrote:
> If a distro adds a SBAT section to either their UKI, or if kernel
> SBAT enforcement is turned on from GRUB2 by default, there is one
> piece missing that would need  to be handled by the mainline kernel
> which is SBAT enforcement for kexec. This  would mean the revocations
> SBAT protect against would need to be referenced  before doing the
> signature validation in kexec. If this is not added, any distro that 
> allows kexec really doesn’t have a SBAT protected kernel.

Um, actually, this is actually one of the misunderstandings of the
whole thread: sbat is a revocation mechanism for protecting EFI boot
security.  It's design is to prevent malicious actors exploiting buggy
code to get into the EFI boot system before ExitBootServices is called
and nothing more.  The kernel's intrusion into EFI boot security is
tiny: it's basically the EFI stub up to ExitBootServices, so even if
the kernel were to have an sbat number it would obviously be under the
control of the maintainers of only that code (i.e. Ard) and it would
only rev if we actually found a usable exploit in the efi stub.

As far as kexec is concerned, ExitBootServices is long gone and nothing
a future kexec'd kernel can do can alter that, so there's no EFI
security benefit to making kexec sbat aware, and thus it seems there's
no need to do anything about it for kexec.  Now if we're interested in
sbat as a more general revocation mechanism, that might change, but I
think sbat is too tightly designed for the problems of EFI variables to
be more generally useful.

James