arch/x86/boot/Makefile | 2 +- arch/x86/boot/compressed/Makefile | 5 ++++ arch/x86/boot/compressed/sbat.S | 7 +++++ arch/x86/boot/compressed/vmlinux.lds.S | 8 ++++++ arch/x86/boot/header.S | 31 +++++++++++++++------ drivers/firmware/efi/Kconfig | 24 ++++++++++++++++ drivers/firmware/efi/libstub/Makefile.zboot | 4 +++ drivers/firmware/efi/libstub/zboot-header.S | 22 +++++++++++++-- drivers/firmware/efi/libstub/zboot.lds | 11 ++++++++ 9 files changed, 102 insertions(+), 12 deletions(-) create mode 100644 arch/x86/boot/compressed/sbat.S
Changes since v2 (Ard): (https://lore.kernel.org/linux-efi/20250505154523.231233-1-vkuznets@redhat.com/) - Use 'textsize' intermediary in arch/x86/boot/header.S to avoid additional '#ifdef CONFIG_EFI_SBAT'. - Fix indentation. - Added R-b tags. Original description: SBAT is a mechanism which improves SecureBoot revocations of UEFI binaries by introducing a generation-based technique. Compromised or vulnerable UEFI binaries can be prevented from booting by bumping the minimal required generation for the specific component in the bootloader. More information on the SBAT can be obtained here: https://github.com/rhboot/shim/blob/main/SBAT.md Currently, shim checks .sbat data for itself in self-test and for second stage bootloaders (grub, sd-boot, UKIs with sd-stub, ...) but kernel revocations require cycling signing keys or adding kernel hashes to shim's internal dbx. Adding .sbat to kernel and enforcing it on kernel loading will allow to do the same tracking and revocation distros are already doing with a simplified mechanism, and without having to keep lists of kernels outside of the git repos. Previously, an attempt was made to add ".sbat" section to the linux kernel: https://lwn.net/Articles/938422/ The approach was rejected mainly because currently there's no policy on how to update SBAT generation number when a new vulnerability is discovered. In particular, it is unclear what to do with stable kernels which may or may not backport certain patches making it impossible to describe the current state with a simple number. This series suggests a different approach: instead of defining SBAT information, provide a mechanism for downstream kernel builders (distros) to include their own SBAT data. This leaves the decision on the policy to the distro vendors. Basically, each distro implementing SecureBoot today, will have an option to inject their own SBAT data during kernel build and before it gets signed by their SecureBoot CA. Different distro do not need to agree on the common SBAT component names or generation numbers as each distro ships its own 'shim' with their own 'vendor_cert'/'vendor_db'. Linux upstream will never, ever need to care about the data unless they choose in the future to participate in that way. Vitaly Kuznetsov (2): efi: zboot specific mechanism for embedding SBAT section x86/efi: Implement support for embedding SBAT data for x86 arch/x86/boot/Makefile | 2 +- arch/x86/boot/compressed/Makefile | 5 ++++ arch/x86/boot/compressed/sbat.S | 7 +++++ arch/x86/boot/compressed/vmlinux.lds.S | 8 ++++++ arch/x86/boot/header.S | 31 +++++++++++++++------ drivers/firmware/efi/Kconfig | 24 ++++++++++++++++ drivers/firmware/efi/libstub/Makefile.zboot | 4 +++ drivers/firmware/efi/libstub/zboot-header.S | 22 +++++++++++++-- drivers/firmware/efi/libstub/zboot.lds | 11 ++++++++ 9 files changed, 102 insertions(+), 12 deletions(-) create mode 100644 arch/x86/boot/compressed/sbat.S -- 2.49.0
On Tue, 13 May 2025 at 14:58, Vitaly Kuznetsov <vkuznets@redhat.com> wrote: > > Changes since v2 (Ard): > (https://lore.kernel.org/linux-efi/20250505154523.231233-1-vkuznets@redhat.com/) > - Use 'textsize' intermediary in arch/x86/boot/header.S to avoid additional > '#ifdef CONFIG_EFI_SBAT'. > - Fix indentation. > - Added R-b tags. > > Original description: > > SBAT is a mechanism which improves SecureBoot revocations of UEFI binaries > by introducing a generation-based technique. Compromised or vulnerable UEFI > binaries can be prevented from booting by bumping the minimal required > generation for the specific component in the bootloader. More information > on the SBAT can be obtained here: > > https://github.com/rhboot/shim/blob/main/SBAT.md > > Currently, shim checks .sbat data for itself in self-test and for second > stage bootloaders (grub, sd-boot, UKIs with sd-stub, ...) but kernel > revocations require cycling signing keys or adding kernel hashes to shim's > internal dbx. Adding .sbat to kernel and enforcing it on kernel loading > will allow to do the same tracking and revocation distros are already > doing with a simplified mechanism, and without having to keep lists of > kernels outside of the git repos. > > Previously, an attempt was made to add ".sbat" section to the linux kernel: > > https://lwn.net/Articles/938422/ > > The approach was rejected mainly because currently there's no policy on how > to update SBAT generation number when a new vulnerability is discovered. In > particular, it is unclear what to do with stable kernels which may or may > not backport certain patches making it impossible to describe the current > state with a simple number. > > This series suggests a different approach: instead of defining SBAT > information, provide a mechanism for downstream kernel builders (distros) > to include their own SBAT data. This leaves the decision on the policy to > the distro vendors. Basically, each distro implementing SecureBoot today, > will have an option to inject their own SBAT data during kernel build and > before it gets signed by their SecureBoot CA. Different distro do not need > to agree on the common SBAT component names or generation numbers as each > distro ships its own 'shim' with their own 'vendor_cert'/'vendor_db'. Linux > upstream will never, ever need to care about the data unless they choose in > the future to participate in that way. > > Vitaly Kuznetsov (2): > efi: zboot specific mechanism for embedding SBAT section I've picked up the first patch for the next cycle. The second one can then go via the -tip tree for v6.17 Or if team-tip is happy to pick it up now, I've created a separate efi-sbat branch with only the first patch, so it can be merged into -tip and the second patch applied on top. git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi.git efi-sbat > x86/efi: Implement support for embedding SBAT data for x86 > > arch/x86/boot/Makefile | 2 +- > arch/x86/boot/compressed/Makefile | 5 ++++ > arch/x86/boot/compressed/sbat.S | 7 +++++ > arch/x86/boot/compressed/vmlinux.lds.S | 8 ++++++ > arch/x86/boot/header.S | 31 +++++++++++++++------ > drivers/firmware/efi/Kconfig | 24 ++++++++++++++++ > drivers/firmware/efi/libstub/Makefile.zboot | 4 +++ > drivers/firmware/efi/libstub/zboot-header.S | 22 +++++++++++++-- > drivers/firmware/efi/libstub/zboot.lds | 11 ++++++++ > 9 files changed, 102 insertions(+), 12 deletions(-) > create mode 100644 arch/x86/boot/compressed/sbat.S > > -- > 2.49.0 >
© 2016 - 2026 Red Hat, Inc.