On 16 September 2015 at 12:08, Borislav Petkov <bp@xxxxxxx> wrote: > On Wed, Sep 09, 2015 at 12:21:23PM +0100, Matt Fleming wrote: >> On Wed, 09 Sep, at 08:33:07AM, joeyli wrote: >> > >> > Yes, the machine on my hand has EFI_PROPERTIES_TABLE enabled, and it doesn't >> > boot without your patch. >> >> Awesome. Could you test the following patch instead? >> >> --- >> >> From 24d324b781a3b688dcc265995949a9cf4e8af687 Mon Sep 17 00:00:00 2001 >> From: Matt Fleming <matt.fleming@xxxxxxxxx> >> Date: Thu, 3 Sep 2015 15:56:25 +0100 >> Subject: [PATCH v2] x86/efi: Map EFI memmap entries in-order at runtime >> >> Beginning with UEFI v2.5 EFI_PROPERTIES_TABLE was introduced that >> signals that the firmware PE/COFF loader supports splitting code and >> data sections of PE/COFF images into separate EFI memory map entries. >> This allows the kernel to map those regions with strict memory >> protections, e.g. EFI_MEMORY_RO for code, EFI_MEMORY_XP for data, etc. >> >> Unfortunately, an unwritten requirement of this new feature is that >> the regions need to be mapped with the same offsets relative to each >> other as observed in the EFI memory map. If this is not done crashes > > Let me get this straight: this looks like the next EFI screwup which > practically requires specific mapping placement in VA space just > because it uses relative addresses? Both relative and absolute references, currently. The latter are also affected since the relocation offset that is applied to all PE/COFF relocation entries is based on the displacement of ImageBase, and absolute references to symbols in .data need to be treated specially (since it may be shifted relative to the .text section containing ImageBase). This could be worked around by converting each absolute reference individually using ConvertPointer () [and I have a proof of concept that actually makes the problem go away on x86] but it would still be only a partial solution, since relative references are not tracked in the PE/COFF metadata, so even if we wanted to, it would be intractible to find each cross-section relative reference and do the fixup. > And since you say "unwritten" this > practically a requirement is not even in the spec? > No, it seems nobody thought of this when designing the feature. > Can we state explicitly in the spec NOT to rely on mapping VA placement? > I mean, this "unwritten" requirement is seriously screwed on soo many > levels... > Several solutions and/or work arounds are currently under discussion -- Ard. > What else are we to expect? Spelled out virtual addresses which are > going to be the EFI-allowed ones only??! > > -- > Regards/Gruss, > Boris. > > SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) > -- -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
