Re: [PATCH v3] x86/corruption-check: Remove the BIOS memory corruption check feature

[H. Peter Anvin]

On October 10, 2026 12:45:19 PM PDT, Borislav Petkov <bp@xxxxxxxxx> wrote:
>On Sat, Oct 10, 2026 at 11:36:04AM -0400, Luiz Capitulino wrote:
>> By default, the BIOS memory corruption check works by reserving the
>> first 64 KiB physical area from memblock, zeroing it and then scanning it
>> periodically.
>> 
>> However, this functionality has been broken in its default configuration
>> since v5.13 by two commits:
>> 
>> - Commit a799c2bd29d1 ("x86/setup: Consolidate early memory reservations").
>>   Moved trim_low_memory_range() into early_reserve_memory(), which runs
>>   earlier in setup_arch(), causing the first 64 KiB to be reserved (when
>>   CONFIG_X86_RESERVE_LOW=64) before setup_bios_corruption_check() runs
>> 
>> - Commit f1d4d47c5851 ("x86/setup: Always reserve the first 1M of RAM").
>>   Hardcodes the reservation of the first 64 KiB early in
>>   early_reserve_memory()
>> 
>> It might be possible to get the default case to work by allowing
>> setup_bios_corruption_check() to run first, but it's just not worth it
>> given that the kernel will never access the first 64 KiB area anyway.
>> 
>> Lastly, note that it's possible to get the corruption check to work with
>> a different region by passing memory_corruption_check_size=. However,
>> the main goal of the feature was to check the first 64 KiB. Besides,
>> the region picked will be almost random as setup_bios_corruption_check()
>> will pick a region by size.
>
>And?
>
>Do I want this or should it be fixed or the first 64K are not worth it to
>check or...?
>
>That whole "rationale" is not really clear to me. Yes, it is broken,
>apparently. So let's remove it but we might get it work still... So which is
>it and why?
>

We aren't using that memory, so there is no point spending the time scanning it periodically.