Re: EFI table being corrupted during Kexec

["Eric W. Biederman" <ebiederm@xmission.com>]

Breno Leitao <leitao@debian.org> writes:

> Hello Eric,
>
> On Tue, Sep 10, 2024 at 09:26:00AM -0500, Eric W. Biederman wrote:
>> > I am wondering if that memory region/range should be part of e820 table that is
>> > passed by EFI firmware to kernel, and if it is not passed (as it is not being
>> > passed today), then the kernel doesn't need to respect it, and it is free to
>> > overwrite (as it does today). In other words, this is a firmware bug and not a
>> > kernel bug.
>> >
>> > Am I missing something?
>> 
>> I agree that this appears to be a firmware bug.  This memory is reserved
>> in one location and not in another location.
>
> That was is our current understanding also, but, having the same issue
> in EDK2 and on a real machine firmware was surprising.
>
> Anyway, I've CCed the EDK2 mailing list in this thread as well, let's
> see if someone has any comment.
>
>> As I recall the memblock allocator is the bootstrap memory allocator
>> used when bringing up the kernel.  So I don't see reserving something
>> in the memblock allocator as being authoritative as to how the firmware
>> has setup memory.
>> 
>> I would suggest writing a patch to update whatever is calling
>> memblock_reserve to also, or perhaps in preference to update the e820
>> map.  If the code is not x86 specific I would suggest using ACPI's
>> arch_reserve_mem_area call.
>
> Should all memblock_reserve() memory ranges be mapped to e820 table, or,
> just specific cases where we see problems?

Just specific cases.  There could be other linux specific reasons to
tell the memblock allocator not to allocation from a specific range
of memory.

Eric