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
