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

[Ard Biesheuvel]

On Tue, 13 May 2025 at 14:58, Vitaly Kuznetsov <vkuznets at 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
>