Re: [PATCH RFC] x86/efi: Add a mechanism for embedding SBAT section

[Ard Biesheuvel]

On Fri, 7 Mar 2025 at 14:29, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote:
>
>   Hi,
>
> > > This patch suggests a different approach: instead of defining SBAT
> > > information, provide a mechanism for downstream kernel builders (distros)
> > > to include their own SBAT data.
> >
> > Why does this require a mechanism in the upstream kernel at all?
>
> To avoid every distro re-inventing the wheel?
>

Fair enough.

> > > - CRC32 must be at the end of the file.
> >
> > We never cared about the CRC32 before with signed EFI images, which
> > gets clobbered when the image is signed. Why should we start caring
> > about it now?
>
> I have some blurry memories on having seen this crc32 discussion
> before ...
>
> The crc32 is not clobbered.  The signature is simply appended and
> wouldn't overwrite the crc32.  But if software expects to find that
> crc32 in the last four bytes of the file then yes, that assumption does
> not hold any more for signed kernel binaries.
>

The crc32 is a CRC over the entire bzImage. Whether or not it lives at
the end is irrelevant, as signing the bzImage will necessarily [*]
break the CRC, and subsequently regenerating the CRC will invalidate
the signature. (The CRC lives at the end because that is the easiest
way to generate an image whose checksum including the CRC itself is
~0. However, there are also other ways to achieve this)

> Who uses that crc32 and how?  If it is useless anyway, can we just drop
> it upstream?
>

I tried but hpa objected to that. [0]

> > Please don't create a special case for x86 again - iff this needs to
> > be in upstream (which I am not convinced about) it needs to be
> > implemented for all architectures.
>
> Well, x86 *is* the special case.  Everybody else just uses zboot.
>
> But, yes, when this RfC patch discussion comes to the conclusion that
> this is useful to have upstream the plan is to do this for zboot too
> so all architectures are covered.
>

Good.

> > So I'd like to understand better what is preventing you from appending
> > a PE/COFF section on an arbitrary bzImage (or EFI zboot image).
>
> Well, assuming it is safe to ignore the crc32 as per above discussion
> then nothing really.  It should be possible to do this as part of the
> signing process instead.  That leaves the "not re-inventing the wheel"
> aspect of this on the table.
>

[*] While it is feasible to generate an image that checksums to ~0 and
is signed for UEFI secure boot (details in [0]), I seriously doubt
that we should bother. Not even hpa's own bootloader 'syslinux' cares
about the CRC-32, and given that all signed distro kernels that have
been in circulation since they started signing them have corrupted
CRCs, there is really no need to start caring about that now.

If there is a need to maintain this upstream, we can host the tools
but I don't see a reason to integrate this with the bzImage build as
this patch proposes.





[0] https://lore.kernel.org/all/20230818134422.380032-1-ardb@xxxxxxxxxx/T/#m3d3c7b62045072090c49706295a1fc9aa6a5e349