On March 7, 2025 7:29:27 AM PST, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: >On Fri, 7 Mar 2025 at 15:52, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> >> On March 7, 2025 6:15:27 AM PST, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: >> >On Fri, 7 Mar 2025 at 14:29, Gerd Hoffmann <kraxel@xxxxxxxxxx> wrote: >> >> >... >> >> 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] >> > >... >> >> I don't remember who it was that asked for the CRC32 long ago. It wasn't for Syslinux; it was for an embedded boot loader which didn't have a file system. >> >> I don't know what would break, and it is obviously a mess that the signing protocol didn't take that into consideration, but that is water under the bridge, too. >> >> We could try zeroing out the CRC field and see if anyone screams... >> > >If dropping the CRC is on the table, we might also consider my >original patch, which gets rid of the build tool entirely, given the >fact that generating the CRC is the only thing it is still used for. >(Either change can easily be reverted anyway) I think it would have to be up to the x86 maintainers, but I would be willing to test it. Perhaps it would be better, though, to make the CRC a build option – or we make it mutually exclusive with efistub.
