linux-kernel - Re: [tip: x86/build] x86/boot: Add back some padding for the CRC-32 checksum

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: <89CE5702-6C52-4E02-9A18-31E4161CA677@zytor.com>
Date: Tue, 15 Apr 2025 10:00:11 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Ard Biesheuvel <ardb@...nel.org>, Borislav Petkov <bp@...en8.de>
CC: linux-kernel@...r.kernel.org, linux-tip-commits@...r.kernel.org,
        Ingo Molnar <mingo@...nel.org>, Ian Campbell <ijc@...lion.org.uk>,
        Linus Torvalds <torvalds@...ux-foundation.org>, x86@...nel.org
Subject: Re: [tip: x86/build] x86/boot: Add back some padding for the CRC-32 checksum

On April 14, 2025 7:07:53 AM PDT, Ard Biesheuvel <ardb@...nel.org> wrote:
>On Mon, 14 Apr 2025 at 15:56, Borislav Petkov <bp@...en8.de> wrote:
>>
>> On Wed, Mar 12, 2025 at 12:09:34PM -0000, tip-bot2 for Ard Biesheuvel wrote:
>> > The following commit has been merged into the x86/build branch of tip:
>> >
>> > Commit-ID:     e471a86a8c523eccdfd1c4745ed7ac7cbdcc1f3f
>> > Gitweb:        https://git.kernel.org/tip/e471a86a8c523eccdfd1c4745ed7ac7cbdcc1f3f
>> > Author:        Ard Biesheuvel <ardb@...nel.org>
>> > AuthorDate:    Wed, 12 Mar 2025 09:12:05 +01:00
>> > Committer:     Ingo Molnar <mingo@...nel.org>
>> > CommitterDate: Wed, 12 Mar 2025 13:04:52 +01:00
>> >
>> > x86/boot: Add back some padding for the CRC-32 checksum
>> >
>> > Even though no uses of the bzImage CRC-32 checksum are known, ensure
>> > that the last 4 bytes of the image are unused zero bytes, so that the
>> > checksum can be generated post-build if needed.
>>
>> Sounds like it is not needed and sounds like we should whack this thing no?
>>
>> Or are we doing a grace period and then whack it when that grace period
>> expires?
>>
>
>This was done on hpa's request - maybe he has a duration in mind for
>this grace period?

I would prefer to leave it indefinitely, because an all zero pattern is far easier to detect than what would look like a false checksum.

So I remembered eventually who wanted it: it was a direct from flash boot loader who wanted to detect a partial flash failure before invoking the kernel, so that it can redirect to a secondary kernel.

That would obviously not be an UEFI environment, so the signing issue is not applicable.

An all zero end field actually works for that purpose (although requires a boot loader patch), because an unprogrammed flash sector contains FFFFFFFF not 00000000.

We have kept the bzImage format backwards compatible – sometimes at considerable effort – and the cost of reasonably continuing to do so is absolutely minimal. This is an incompatible change, so at least it is appropriate to give unambiguous indication thereof.

In other words: it ain't broken, don't try to fix it. It is all downside, no upside.