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] [day] [month] [year] [list]

Message-ID: <82D253A5-FD13-4530-BC1D-237EF42B9E07@zytor.com>
Date: Fri, 07 Mar 2025 07:39:22 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Ard Biesheuvel <ardb@...nel.org>
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 March 7, 2025 7:29:27 AM PST, Ard Biesheuvel <ardb@...nel.org> wrote:
>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)

I think it would have to be up to the x86 maintainers, but I would be willing to test it. Perhaps it would be better, though, to make the CRC a build option – or we make it mutually exclusive with efistub.