> On Jul 20, 2023, at 11:07 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > > 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. If the line of protection SBAT provides ends at EBS then I agree, kexec support would not be needed. While reading the SBAT spec, I got the impression the revocation mechanism it provides would go beyond the EBS line. I guess that needs to be clarified.
