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: <885FB3F6-B085-45DE-9710-10563322B61A@zytor.com>
Date: Fri, 07 Mar 2025 06:52:17 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Ard Biesheuvel <ardb@...nel.org>, Gerd Hoffmann <kraxel@...hat.com>
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>,
        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 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:
>>
>>   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?
>>
>
>Fair enough.
>
>> > > - 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.
>>
>
>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]
>
>> > 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.
>>
>
>Good.
>
>> > 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.
>>
>
>[*] While it is feasible to generate an image that checksums to ~0 and
>is signed for UEFI secure boot (details in [0]), I seriously doubt
>that we should bother. Not even hpa's own bootloader 'syslinux' cares
>about the CRC-32, and given that all signed distro kernels that have
>been in circulation since they started signing them have corrupted
>CRCs, there is really no need to start caring about that now.
>
>If there is a need to maintain this upstream, we can host the tools
>but I don't see a reason to integrate this with the bzImage build as
>this patch proposes.
>
>
>
>
>
>[0] https://lore.kernel.org/all/20230818134422.380032-1-ardb@kernel.org/T/#m3d3c7b62045072090c49706295a1fc9aa6a5e349

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...