Where is SBAT data for Linux kernel images found?

[mcb30]

Current versions of shim (from 15.3 onwards) will refuse to invoke a second stage loader that does not have an .sbat data section: https://github.com/rhboot/shim/blob/f23883ccf78f1f605a272f9e5700f47e5494a71d/pe.c#L844-L852

As far as I can tell, Linux kernels do not include an .sbat section. There is no sign of SBAT support within the kernel sources, and objdump -x confirms that at least current Fedora kernels do not have .sbat.

There is some reference in https://github.com/rhboot/shim/blob/f23883ccf78f1f605a272f9e5700f47e5494a71d/SBAT.md#kernel-support-for-sbat to separate SBAT-containing files for the kernel:

Until a component (e.g. the Linux kernel) gains SBAT metadata it can not be revoked via SBAT, but only by revoking the keys signing that component. These keys will live in separate, product-specific signed PE files that contain only the certificate and SBAT metadata for the key files.

However, I can find no existent examples of such a key file, and from looking through the code I don't see any way that shim would be able to consume these files even if they existed.

So, questions:

• Is shim supposed to still be usable for directly invoking a suitably signed kernel binary, or is shim now considered to be just one half of a shim+GRUB ecosystem, in which GRUB is a hard requirement for invoking a kernel?
• If shim is supposed to still be usable for directly invoking a suitably signed kernel binary, then where is the kernel's SBAT data supposed to exist?

[julian-klode]

Kernels to my knowledge have no SBAT ability yet, so you need to either build a UKI with the systemd-boot stub with SBAT section in it, or use grub. Maybe you can objcopy a .sbat section into a raw kernel PE image too, I do not know.

[mcb30]

@julian-klode Thank you for the information.

Building a custom UKI will produce a binary without any distro Secure Boot signature, and using objcopy to add an .sbat section to an existing kernel image would invalidate its existing distro Secure Boot signature, so unfortunately neither of those are viable options.

Is the intention that the kernel should eventually gain SBAT support, or is this not even a planned feature?

[frozencemetery]

Is the intention that the kernel should eventually gain SBAT support

Yes.

or is this not even a planned feature?

False dichotomy.

[mcb30]

Is the intention that the kernel should eventually gain SBAT support

Yes.

Great, thanks! Any chance you could you point me towards the mailing list posts to add it? I can't find them, sorry.

or is this not even a planned feature?

False dichotomy.

...?

[frozencemetery]

Intention is not execution. Just because something should happen does not mean it currently is.

False dichotomy occurs when a relationship of the form "Either a, or b" is expressed while a and b are either not mutually exclusive or the union of a and b does not fully cover the range of possibility. In this case, the second: it is not correct to assume that something is either intended or not planned.

[mcb30]

Intention is not execution. Just because something should happen does not mean it currently is.

False dichotomy occurs when a relationship of the form "Either a, or b" is expressed while a and b are either not mutually exclusive or the union of a and b does not fully cover the range of possibility. In this case, the second: it is not correct to assume that something is either intended or not planned.

OK, so it sounds as though you're saying there is a general vague intention that the kernel should at some undefined future point gain SBAT support, but that as far as you know nobody has yet done anything about it and nobody is actively working on it. Is this a fair summary?

[berrange]

OK, so it sounds as though you're saying there is a general vague intention that the kernel should at some undefined future point gain SBAT support, but that as far as you know nobody has yet done anything about it and nobody is actively working on it. Is this a fair summary?

FYI there was a somewhat painful thread on this topic the past week or two:

https://lore.kernel.org/lkml/20230711154449.1378385-1-eesposit@redhat.com/

TL;DR; there is strong pushback against the idea of adding SBAT info upstream. Unless something changes in this POV, any SBAT info added to the kernel binaries is likely to end up being a downstream only vendor addition at the time they build and sign their kernel images.

[mcb30]

OK, so it sounds as though you're saying there is a general vague intention that the kernel should at some undefined future point gain SBAT support, but that as far as you know nobody has yet done anything about it and nobody is actively working on it. Is this a fair summary?

FYI there was a somewhat painful thread on this topic the past week or two:

https://lore.kernel.org/lkml/20230711154449.1378385-1-eesposit@redhat.com/

Ouch. Thanks for your efforts in trying to get SBAT upstreamed.

For now, we've had to work around it in iPXE by disabling the SBAT check in shim. I don't like doing this (because SBAT is a sane mechanism), but if the generally available signed distro kernels don't include SBAT sections then we have no alternative available to us. :cry: