[REGRESSION] kexec does firmware reboot in kernel v6.7.6
David Woodhouse
dwmw2 at infradead.org
Wed Oct 23 04:39:59 PDT 2024
On Wed, 2024-10-23 at 06:07 -0500, Kalra, Ashish wrote:
>
> As mentioned above, about the same 2MB page containing the end portion of the RMP table and a page allocated for kexec and
> looking at the e820 memory map dump here:
>
> > > > [ 0.000000] BIOS-e820: [mem 0x000000bfbe000000-0x000000c1420fffff] reserved
> > > > [ 0.000000] BIOS-e820: [mem 0x000000c142100000-0x000000fc7fffffff] usable
>
> As seen here in the e820 memory map, the end range of the RMP table is not
> aligned to 2MB and not reserved but it is usable as RAM.
>
> Subsequently, kexec-ed kernel could try to allocate from within that chunk
> which then causes a fatal RMP fault.
Well, allocating within that chunk would be just fine. It *is* usable
as RAM, as the e820 table says. It works fine most of the time.
You've missed a step out of the story. The problem is that for kexec we
map it with an "overreaching" 2MiB PTE which also covers the reserved
regions, and *that* is what causes the RMP violation fault.
We could take two possible viewpoints here. I was taking the viewpoint
that this is a kernel bug, that it *shouldn't* be setting up 2MiB pages
which include a reserved region, and should break those down to 4KiB
pages.
The alternative view would be to consider it a BIOS bug, and to say
that the BIOS really *ought* to have reserved the whole 2MiB region to
avoid the 'sharing'. Since the hardware apparently already breaks down
1GiB pages to 2MiB TLB entries in order to avoid triggering the problem
on 1GiB mappings.
> This issue has been fixed with the following patch:
> https://lore.kernel.org/lkml/171438476623.10875.16783275868264913579.tip-bot2@tip-bot2/
Thanks for pointing that patch out! Should it have been Cc:stable?
It seems to be taking the latter of the above two viewpoints, that this
is a BIOS bug and that the BIOS *should* have reserved the whole 2MiB.
In that case are fixed BIOSes available already? This patch makes sense
as a temporary workaround (we have ways to print warnings about BIOS
bugs, btw), but I don't really like it as a longer-term "fix". What if
the BIOS had put *other* things into that other 1MiB of address space?
What if the bootloader had loaded something there?
I'm still inclined to suggest that kexec *shouldn't* use over-reaching
large pages which cover anything that isn't marked as usable RAM.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/kexec/attachments/20241023/0d8152f9/attachment-0001.p7s>
More information about the kexec
mailing list