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 for Android: free password hash cracker in your pocket

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

Message-ID: <63vy4xc4mpm5tttdqz5vfzwyriqlminjdiffrbuamxcubmpuur@nxszi7xzxa6a>
Date: Fri, 7 Mar 2025 14:28:55 +0100
From: Gerd Hoffmann <kraxel@...hat.com>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: 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>, 
	"H. Peter Anvin" <hpa@...or.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

  Hi,

> > This patch suggests a different approach: instead of defining SBAT
> > information, provide a mechanism for downstream kernel builders (distros)
> > to include their own SBAT data.
> 
> Why does this require a mechanism in the upstream kernel at all?

To avoid every distro re-inventing the wheel?

> > - CRC32 must be at the end of the file.
> 
> We never cared about the CRC32 before with signed EFI images, which
> gets clobbered when the image is signed. Why should we start caring
> about it now?

I have some blurry memories on having seen this crc32 discussion
before ...

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.

Who uses that crc32 and how?  If it is useless anyway, can we just drop
it upstream?

> Please don't create a special case for x86 again - iff this needs to
> be in upstream (which I am not convinced about) it needs to be
> implemented for all architectures.

Well, x86 *is* the special case.  Everybody else just uses zboot.

But, yes, when this RfC patch discussion comes to the conclusion that
this is useful to have upstream the plan is to do this for zboot too
so all architectures are covered.

> So I'd like to understand better what is preventing you from appending
> a PE/COFF section on an arbitrary bzImage (or EFI zboot image).

Well, assuming it is safe to ignore the crc32 as per above discussion
then nothing really.  It should be possible to do this as part of the
signing process instead.  That leaves the "not re-inventing the wheel"
aspect of this on the table.

take care,
  Gerd