[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXGw5_pLx=+RSFndd6PxXBe5-TyOmWDpyD5v4+YhOxYMBA@mail.gmail.com>
Date: Mon, 21 Aug 2023 09:04:38 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
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 Mon, 21 Aug 2023 at 02:37, H. Peter Anvin <hpa@...or.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.
Powered by blists - more mailing lists