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 <l...@amacapital.net> wrote: >On Fri, Sep 25, 2015 at 10:56 PM, Ingo Molnar <mi...@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 <m...@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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
