| Message ID | 20230818134422.380032-1-ardb@kernel.org |
|---|---|
| Headers | show |
| Series | x86/boot: Rework PE header generation | expand |
On 8/18/23 06:44, Ard Biesheuvel wrote: > Ancient (pre-2003) x86 kernels could boot from a floppy disk straight from > the BIOS, using a small real mode boot stub at the start of the image > where the BIOS would expect the boot record (or boot block) to appear. > > Due to its limitations (kernel size < 1 MiB, no support for IDE, USB or > El Torito floppy emulation), this support was dropped, and a Linux aware > bootloader is now always required to boot the kernel from a legacy BIOS. > > To smoothen this transition, the boot stub was not removed entirely, but > replaced with one that just prints an error message telling the user to > install a bootloader. > > As it is unlikely that anyone doing direct floppy boot with such an > ancient kernel is going to upgrade to v6.5+ and expect that this boot > method still works, printing this message is kind of pointless, and so > it should be possible to remove the logic that emits it. > > Let's free up this space so it can be used to expand the PE header in a > subsequent patch. > > Signed-off-by: Ard Biesheuvel <ardb@kernel.org > Good riddance. Acked-by: H. Peter Anvin (Intel) <hpa@zytor.com>
On Sun, 20 Aug 2023 at 03:03, H. Peter Anvin <hpa@zytor.com> wrote: > > > > On 8/18/23 06:44, Ard Biesheuvel wrote: > > The only remaining task carried out by the boot/tools/build.c build tool > > is generating the CRC-32 checksum of the bzImage. This feature was added > > in commit > > > > 7d6e737c8d2698b6 ("x86: add a crc32 checksum to the kernel image.") > > > > without any motivation (or any commit log text, for that matter). This > > checksum is not verified by any known bootloader, and given that > > > > a) the checksum of the entire bzImage is reported by most tools (zlib, > > rhash) as 0xffffffff and not 0x0 as documented, > > b) the checksum is corrupted when the image is signed for secure boot, > > which means that no distro ships x86 images with valid CRCs, > > > > it seems quite unlikely that this checksum is being used, so let's just > > drop it, along with the tool that generates it. > > > > This one I have concerns with. > 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.
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. -hpa
On Mon, 21 Aug 2023 at 02:37, H. Peter Anvin <hpa@zytor.com> 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.