Re: Can EFI memory descriptors overlap? [PING v1]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 18 Oct 2021 at 20:49, Martin Fernandez
<martin.fernandez@xxxxxxxxxxxxx> wrote:
>
> Hi, I'm working on the rework of
> https://lore.kernel.org/linux-efi/CAMj1kXEqjHVRNV131=o_aO3TX+58xhYzgfaVDrd0RngAqqtrVg@xxxxxxxxxxxxxx/T/
> and I wanted to know if the memory map given by EFI have any guarantee
> that the regions don't overlap.
>

Please don't ask people to refer to postings that are legally dubious.
I understand that this may sound exaggerated to you, but it is the
reality of open source.

> I couldn't find anything in the UEFI spec, but there is a piece of
> code in the kernel that seems to "doesn't care" and assumes that the
> regions given by EFI are sorted and don't overlap.
>

In my experience with EDK2 based UEFI firmware, the entries covering
system DRAM are usually sorted, with additional MMIO entries appearing
unordered. This is because the UEFI memory map is constructed from the
GCD memory map, which is seeded with the DRAM regions at boot, and
allocations are created by splitting them up.

> https://elixir.bootlin.com/linux/latest/source/arch/x86/platform/efi/efi.c#L502
>
> static void __init efi_merge_regions(void)
> {
>     efi_memory_desc_t *md, *prev_md = NULL;
>
>     for_each_efi_memory_desc(md) {
>         u64 prev_size;
>
>         if (!prev_md) {
>             prev_md = md;
>             continue;
>         }
>
>         if (prev_md->type != md->type ||
>             prev_md->attribute != md->attribute) {
>             prev_md = md;
>             continue;
>         }
>
>         prev_size = prev_md->num_pages << EFI_PAGE_SHIFT;
>
>         if (md->phys_addr == (prev_md->phys_addr + prev_size)) {
>             prev_md->num_pages += md->num_pages;
>             md->type = EFI_RESERVED_TYPE;
>             md->attribute = 0;
>             continue;
>         }
>         prev_md = md;
>     }
> }
>
> Is this a bug or in practice EFI always gives a "nice" memory map?

I agree that this practice has no basis in the spec.

> I
> think that if there is no overlap then the sorting (EFI doesn't give
> me a sorted memory map on my machine) is a kind of easy problem to
> solve, but if there is overlap involved then we need to decide for the
> type and the attributes of those overlaps, which can be tricky.
>
> I'm working on x86 and with the master branch of the kernel.

Overlap is another matter, though. Overlap means that the EFI memory
map is ambiguous, and contains more than one description of the same
memory region. Since the spec does not describe this case, I will pull
the 'undefined behavior' card, and propose that we pretend that those
can never occur.

-- 
Ard.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux