Folks,


The problem: *secure boot* directly via EFI stub on a system,
where the necessary key management options are not present
(disabled by the OEM) in the BIOS.

Unless one is prepared to hack that BIOS, following, say
https://lukegb.com/posts/2016-11-11-secure-boot-shenanigans/
the standard approach would be to use SHIM (and MOK):
https://github.com/rhboot/shim

A few years back, CVE-2020-10713 ("BootHole") prompted
what one might call a lightweight revocation solution:
Secure Boot Advanced Targeting (SBAT).
https://github.com/rhboot/shim/blob/main/SBAT.md

As a result, SHIM flatly refuses to load an EFI binary without
an embedded SBAT section.

Adding SBAT to a "plain" kernel, as described, for instance here:
https://www.rodsbooks.com/efi-bootloaders/secureboot.html#sbat
works fine, but doing the same for a kernel with EFI stub 
messes up the binary and results in a boot loop. That's,
perhaps, not surprising considering that the intervention
also changes the file's signature:
```
$ file bzImage-6.12.9-gentoo
bzImage-6.12.9-gentoo: Linux kernel x86 boot executable bzImage, version 6.12.9-gentoo ...
$ objcopy --set-section-alignment '.sbat=512' --add-section .sbat=sbat.csv --adjust-section-vma .sbat+10000000 bzImage-6.12.9-gentoo
$ file bzImage-6.12.9-gentoo
bzImage-6.12.9-gentoo: PE32+ executable (EFI application) x86-64 (stripped to external PDB), for MS Windows, 4 sections
$
```

NB: I have NOT tried the `pe-add-sections.py` script linked from
https://github.com/rhboot/shim/issues/376#issuecomment-1628004034
but I'd expect similar results to the `objcopy` case above, since
the EFI stub is a bit "special" in its construction.


BTW, workarounds for secure boot on such a system via OTHER MEANS
than EFI stub do exist.  One could simply employ a bootloader,
or build a Unified Kernel Image using `ukify` that will add both
its own "EFIStub" and an SBAT section to a "plain" kernel.
https://manpages.debian.org/bookworm-backports/systemd/ukify.1.en.html
https://wiki.gentoo.org/wiki/Unified_kernel_image#EFI_stub


I realize that wanting to stick with the kernel's built-in EFI stub
may be a bit of a niche issue, and I do have a WORKSFORME-level hack
to address this for myself (attached, since it's not a proper patch
for review, only a conversation starter); so, this isn't high priority.
I'm only checking if adding SBAT support may be of general interest.

Best,


--andrás


PS

BTW, I wasn't kidding.  My current approach_is_ a hack.

The included `sbat.csv` is for Gentoo (although simple to adapt).
The code blindly uses a fixed (overly large) size for SBAT.
The final binary MUST be renamed to `grubx64.efi` (or similar,
for 32-bit systems); AND, it MUST be enrolled by hash, since
I haven't added any code that might satisfy the "participating
bootloader" requirements.
https://github.com/rhboot/shim/commit/39df41ceb5a793f7db9233a2741d30c55b6a8861

Interestingly, MOK Manager cannot (or doesn't want to?) extract
the hash from a signed binary; so, either the hash must be
enrolled via `mokutil`, or the kernel can be left unsigned...