Messages in this thread | | | Date | Sat, 26 Sep 2015 11:15:57 -0700 | Subject | Re: [PATCH 1/2] x86/efi: Map EFI memmap entries in-order at runtime | From | Ard Biesheuvel <> |
| |
On 26 September 2015 at 10:20, H. Peter Anvin <hpa@zytor.com> wrote: > I think it "works" because the affected BIOSes don't put spaces between the chunks. I have discussed this with Matt. >
Forgive the ASCII art but perhaps an illustration might help:
before the 2.5 feature, PE/COFF runtime images were remapped as illustrated here:
PA VA +---------------+ +---------------+ | | | | | PE/COFF .text | | EFI | | | | Runtime | +- - - - - - - -+ => | Services |----+ | | | Code | | : : | PE/COFF .data | | | | : : | | | | | +---------------+ +---------------+ +---------------+ | | | | | | | | | EFI | : : : : | | Runtime | : : : : +--->| Services | | | | | | Code | +---------------+ +---------------+ | | | | | | | | | PE/COFF .text | | EFI | +---------------+ | | | Runtime | : gap : +- - - - - - - -+ => | Services |---+ +---------------+ | | | Code | | | | | PE/COFF .data | | | | | EFI | | | | | | | Runtime | +---------------+ +---------------+ +---->| Services | | | | | | Code | : : : : | | : : : : | | : : : : +---------------+ : : : : : :
Since the affected symbol references only exist between PE/COFF .text and PE/COFF .data, there is never a problem since each is PE/COFF image is mapped as a single region. However, with the new feature enabled, this no longer holds: PA VA +---------------+ +---------------+ | | | | | PE/COFF .text | | RtServices |----+ | | | Code | | +- - - - - - - -+ => +---------------+ | +---------------+ | | | RtServices | +--->| RtServices | | PE/COFF .data | | Data | | Code | | | | |----+ +---------------+ +---------------+ +---------------+ | : gap : | | | | | +---------------+ : : : : +--->| RtServices | : : : : | Data | | | | | +---------------+ +---------------+ +---------------+ : gap : | | | | +---------------+ | PE/COFF .text | | RtServices |-------->| RtServices | | | | Code | | Code | +- - - - - - - -+ => +---------------+ +---------------+ | | | RtServices | : gap : | PE/COFF .data | | Data |---+ +---------------+ | | | | | | RtServices | +---------------+ +---------------+ +---->| Data | | | | | | | : : : : +---------------+ : : : : : : : : : : : :
The illustration uses gaps, but obviously, this applies equally to inverting the mapping order, since the PE/COFF .text and .data sections will end up out of order.
-- Ard.
> 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.
| |