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.
