On 29 June 2015 at 14:34, Yao, Jiewen <jiewen....@intel.com> wrote: > Hi Ard > Yes, your are right. We do observe similar odd behavior in old > Win7/Win8/Win8.1, and we have to disable it. > Win8 and Win8.1 have OS patch to set adjacent virtual memory map, to resolve > this issue.
I see this as a big problem with the feature, as it breaks backward compatibility. IOW, you won't be able to boot Windows 7 on a UEFI 2.5 system unless you manually disable the feature (in the setup screen, I suppose?) > We also tested Win10, and Suse 11 GM. They are good. > > Would you please share the information on which OS you are using? > I am using the upstream Linux kernel for AArch64. I am not using a distribution. > All in all, if OS cannot guarantee the virtual memory map is adjacent, we > have to disable this feature. > This is backwards: the feature should be implemented such that it cannot be trivially broken by a well-behaving OS. Note that nothing in the SetVirtualAddressMap () implementation suggests that the regions should be adjacent. Perhaps it would have been better to introduce a new memory region type EfiRuntimeServicesPecoffData, so the OS at least knows which regions it should keep adjacent, (i.e., Code and PecoffData regions should be kept together) So does PE/COFF even allow the memory image to deviate from the file image? If so, the correct way is to update the PE/COFF loader and the relocation logic can deal with sections being laid out differently in memory than they are in the file. -- Ard. > -----Original Message----- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, June 29, 2015 6:46 PM > To: edk2-devel@lists.sourceforge.net; Yao, Jiewen; Gao, Liming; Laszlo Ersek; > Justen, Jordan L; Kinney, Michael D; Zeng, Star > Subject: BUG in properties table feature implementation > > Hello all, > > I am running into another problem with the implementation of the UEFI > 2.5 Properties Table feature. It splits PE/COFF images into separate but > adjacent memory regions, only to be able to assign different permissions to > .text and .data sections. This is working fine at boot time. > > However, at runtime, after calling virtual address map, this breaks down > completely. Since the virtual mapping supplied to > SetVirtualAddressMap() does not have to guarantee adjacency between code and > data regions (of which the OS does not know whether they belong together or > not), reapplying the relocations corrupts the memory image and breaks the > runtime services. > > For example, this region > > 0x00005eeb1000-0x00005eeb6fff [Runtime Code] > 0x00005eeb7000-0x00005eec0fff [Runtime Data] > > is mapped on AARCH64 as > > EFI remap 0x000000005eeb1000 => 00000000440a1000 > EFI remap 0x000000005eeb7000 => 00000000440b7000 > > which retains the relative alignment, but adds a 64 KB offset to the second > regions so that the regions can still be mapped with different permissions > when the OS is executing with a 64 KB page size. > > As far as I can tell, this is in accordance with the spec, and was working > fine until I tried to enable the properties table feature. > With that enabled, the two above regions could actually describe one single > PE/COFF image in memory, and the 64 KB offset results in the relocations to > be applied incorrectly. > > I looked at PeCoffLoaderRelocateImageForRuntime () but to me, it is not very > obvious how to solve this. Obviously, our PE/COFF implementation is not > complete since it assumes file offset == memory offset for sections, but this > does not hold anymore for UEFI 2.5 > > I would also like to point out again that this is another result of the fact > that this series was pushed through with any review or testing outside of the > Intel firmware team. For features of this magnitude and complexity, more > scrutiny and testing is obviously required. > > Kind regards, > Ard. ------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
