From: Luiz Capitulino <luizcap@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: x86@kernel.org, tglx@kernel.org, mingo@redhat.com,
dave.hansen@linux.intel.com, hpa@zytor.com,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
corbet@lwn.net, rppt@kernel.org, blum@kernel.org,
david@kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v3] x86/corruption-check: Remove the BIOS memory corruption check feature
Date: Sun, 11 Oct 2026 22:40:26 -0400 [thread overview]
Message-ID: <aae9d468-2dd4-48fb-8e2d-d6997ac8e723@redhat.com> (raw)
In-Reply-To: <20261010194519.GAasqVz2brXiOLegQi@fat_crate.local>
On 10/10/26 3:45 PM, Borislav Petkov 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?
Right, the changelog got convoluted because I tried to document all the
options. Just to make it clear: I don't think it's worth fixing this, so
I'm proposing to remove it.
Here's a rewritten changelog, if you think this is good I'll send v4.
"""
x86/corruption-check: Remove the BIOS memory corruption check feature
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, in its default configuration it has been broken 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
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()
This has been broken for years and nobody reported it, which suggests the
feature might have no users.
It may be possible to fix this by running setup_bios_corruption_check()
earlier, but that's not worth doing: the feature was intended to detect
corruption in the first 64 KiB but the kernel will never access that
range anyway.
Note that one case still "works", which is passing
memory_corruption_check_size= to scan a larger region. But this is not
useful either: the parameter takes a size, not an address range, so what
gets scanned is whatever memblock happens to have free below that size.
Remove the feature.
"""
next prev parent reply other threads:[~2026-10-12 2:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-10 15:36 Luiz Capitulino
2026-10-10 19:45 ` Borislav Petkov
2026-10-12 2:40 ` Luiz Capitulino [this message]
2026-10-12 19:24 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aae9d468-2dd4-48fb-8e2d-d6997ac8e723@redhat.com \
--to=luizcap@redhat.com \
--cc=blum@kernel.org \
--cc=bp@alien8.de \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hpa@zytor.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=rppt@kernel.org \
--cc=tglx@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®