Support for UEFI Secure Boot Advanced Targeting “SBAT” looks like it could be buttoned up in the mainline kernel for the upcoming Linux 6.17 cycle.
UEFI SBAT is for enabling a new mechanism for dealing with UEFI SecureBoot revocations of UEFI binaries. UEFI SBAT aims to better handle vulnerabilities and other issues as part of the boot chain by having each component declare an SBAT generation. When a vulnerability or other fundamental issue is fixed, that generation version can be bumped. In turn systems can increase the minimum SBAT generation version they support to avoid booting outdated/security-ridden components in the bootchain.
More details on UEFI SBAT can be found via the rhboot/shim documentation.
Ahead of the upcoming Linux 6.17 kernel cycle, efi.git’s “next” branch has merged the SBAT code on its side. This adds the Zboot-specific mechanism for embedding an SBAT section:
“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.
…
Upstream Linux kernel does not currently participate in any way in SBAT as there’s no existing policy in how SBAT generation number should be defined. Keep the status quo and provide a mechanism for distro vendors and anyone else who signs their kernel for SecureBoot to include their own SBAT data. This leaves the decision on the policy to the vendor. 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”https://www..com/”vendor_db’Implement support for embedding SBAT data for architectures using zboot (arm64, loongarch, riscv). Put ‘.sbat’ section in between ‘.data’ and ‘.text’ as the former also covers ‘.bss’ and thus must be the last one.”
That merge adds the Linux kernel EFI_SBAT Kconfig build option and then EFI_SBAT_FILE for specifying an embedded SBAT section file path. The code was worked on by Red Hat.
In addition to that SBAT code working its way into the EFI subsystem “next” branch ahead of Linux 6.17, tip/tip.git’s “x86/boot” branch has picked up this patch to support embedding SBAT data for x86 systems.
“Similar to zboot architectures, implement support for embedding SBAT data for x86. Put ‘.sbat’ section in between ‘.data’ and ‘.text’ as the former also covers ‘.bss’ and ‘.pgtable’ and thus must be the last one in the file.”
Barring any issues from being raised in the coming weeks or objections from Linus Torvalds when the next merge window opens, look for this optional UEFI SBAT support to be merged for the Linux 6.17 cycle when that merge window occurs around early August.
