[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d8c2f362-bfe9-560a-541c-a298f8685be1@zytor.com>
Date: Sun, 20 Aug 2023 17:37:01 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: linux-efi@...r.kernel.org, linux-kernel@...r.kernel.org,
Evgeniy Baskov <baskov@...ras.ru>,
Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Jones <pjones@...hat.com>,
Matthew Garrett <mjg59@...f.ucam.org>,
Gerd Hoffmann <kraxel@...hat.com>,
Kees Cook <keescook@...omium.org>,
Marvin Häuser <mhaeuser@...teo.de>
Subject: Re: [PATCH 17/17] x86/boot: Drop CRC-32 checksum and the build tool
that generates it
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
Powered by blists - more mailing lists