mbox series

[v3,0/2] efi: Add a mechanism for embedding SBAT section

Message ID 20250513125808.75510-1-vkuznets@redhat.com
Headers show
Series efi: Add a mechanism for embedding SBAT section | expand

Message

Vitaly Kuznetsov May 13, 2025, 12:58 p.m. UTC 
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