Messages in this thread | | | Subject | Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime | From | "H. Peter Anvin" <> | Date | Sat, 26 Sep 2015 10:20:22 -0700 |
| |
I think it "works" because the affected BIOSes don't put spaces between the chunks. I have discussed this with Matt.
On September 26, 2015 10:01:14 AM PDT, Andy Lutomirski <luto@amacapital.net> wrote: >On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar <mingo@kernel.org> wrote: >> >> So this commit worries me. >> >> This bug is a good find, and the fix is obviously needed and urgent, >but I'm not >> sure about the implementation at all. (I've Cc:-ed a few more x86 low >level >> gents.) >> >> * Matt Fleming <matt@codeblueprint.co.uk> wrote: >>> + /* >>> + * Starting in UEFI v2.5 the EFI_PROPERTIES_TABLE >>> + * config table feature requires us to map all entries >>> + * in the same order as they appear in the EFI memory >>> + * map. That is to say, entry N must have a lower >>> + * virtual address than entry N+1. This is because the >>> + * firmware toolchain leaves relative references in >>> + * the code/data sections, which are split and become >>> + * separate EFI memory regions. Mapping things >>> + * out-of-order leads to the firmware accessing >>> + * unmapped addresses. >>> + * > >I'm clearly missing something. What is EFI doing that it doesn't care >how big the gap between sections is but it still requires them to be >in order? It's not as though x86_64 has an addressing mode that >allows only non-negative offsets. > >--Andy
-- Sent from my Android device with K-9 Mail. Please excuse my brevity.
| |