linux-kernel - Re: [PATCH RFC] x86/efi: Add a mechanism for embedding SBAT section

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXF7Qs=9COU63k8651uEtSh9soOHddSo=Dqdn1kHTuuzoA@mail.gmail.com>
Date: Fri, 7 Mar 2025 16:29:27 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: Gerd Hoffmann <kraxel@...hat.com>, Vitaly Kuznetsov <vkuznets@...hat.com>, x86@...nel.org, 
	linux-efi@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>, 
	Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>, 
	Peter Jones <pjones@...hat.com>, Daniel Berrange <berrange@...hat.com>, 
	Emanuele Giuseppe Esposito <eesposit@...hat.com>, Greg KH <gregkh@...uxfoundation.org>, 
	Luca Boccassi <bluca@...ian.org>, Peter Zijlstra <peterz@...radead.org>, 
	Matthew Garrett <mjg59@...f.ucam.org>, 
	James Bottomley <James.Bottomley@...senpartnership.com>, 
	Eric Snowberg <eric.snowberg@...cle.com>, Paolo Bonzini <pbonzini@...hat.com>, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] x86/efi: Add a mechanism for embedding SBAT section

On Fri, 7 Mar 2025 at 15:52, H. Peter Anvin <hpa@...or.com> wrote:
>
> On March 7, 2025 6:15:27 AM PST, Ard Biesheuvel <ardb@...nel.org> wrote:
> >On Fri, 7 Mar 2025 at 14:29, Gerd Hoffmann <kraxel@...hat.com> 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)