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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

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