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

[H. Peter Anvin]

On April 14, 2025 7:07:53 AM PDT, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote:
>On Mon, 14 Apr 2025 at 15:56, Borislav Petkov <bp@xxxxxxxxx> 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@xxxxxxxxxx>
>> > AuthorDate:    Wed, 12 Mar 2025 09:12:05 +01:00
>> > Committer:     Ingo Molnar <mingo@xxxxxxxxxx>
>> > 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.