Re: [PATCH 17/17] x86/boot: Drop CRC-32 checksum and the build tool that generates it

[Ard Biesheuvel]

On Mon, 21 Aug 2023 at 02:37, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>
> On 8/20/23 05:57, Ard Biesheuvel wrote:
> >
> > I understand. I deliberately put this change at the very end because I
> > was anticipating some debate on this.
> >
> > Do you have any recollection of why this CRC32 was introduced in the
> > first place? The commit logs are empty and the lore thread doesn't
> > contain any justification either.
>  >
>
> The justification is that firmware is notoriously unreliable and gives
> the boot loader an independent way to verify the load and have a
> fallback, rather than jumping to the kernel and having the decompressor
> fail.
>
> At this time it is impossible to know what might rely on it. The EFI
> signing issue aside, there are a ton of Linux bootloaders for non-EFI
> systems using the BIOS or raw kernel entry points - and there is no
> telling what those environments might do.
>

Fair enough.

The PE header happens to have a checksum field that a) is not used by
EFI at all, and b) is not covered by the signature. So it wouldn't be
too hard to put a doctored value in that field that forces the CRC-32
of the entire image to 0xffff_ffff *after* signing, and this would
even work if the image did not have a CRC-32 at the end in the first
place. (So the signing tools wouldn't need to know whether they are
signing a x86 bzImage or some other PE executable). Note that pesign
and sbsign currently follow the PE/windows spec for generating this
checksum, but EFI never looks at it. (It is documented as being
intended for checksumming critical system DLLs on Windows)

But that is a lot of trouble for no known use case, so let's not
bother with that right now. But I'll withdraw this patch from the
series.

Thanks,
Ard.