mbox series

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

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

Message

Vitaly Kuznetsov May 5, 2025, 3:45 p.m. UTC 
Changes since v1 (Ard):
(https://lore.kernel.org/linux-efi/20250424080950.289864-1-vkuznets@redhat.com/)
- Get back to the idea of putting '.sbat' in between '.text' and '.data' as
  the later also covers '.bss' (and '.pgtable' on x86) which are not present
  in the file but must be accounted for in memory (see the discussion on v1
  for additional details).
- CONFIG_EFI_SBAT is now automatically set when CONFIG_EFI_SBAT_FILE is set.
- Simplified make magic for tracing possible sbat data changes.
- Dropped 'sbat.S' for zboot (x86 stays as there's no good place for it in
  the existing 'vmlinux' compilation units).
- Other necessary tweaks.

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                      | 33 +++++++++++++++------
 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, 104 insertions(+), 12 deletions(-)
 create mode 100644 arch/x86/boot/compressed/sbat.S