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. We also tested Win10, and Suse 11 GM. They are good.
Would you please share the information on which OS you are using? All in all, if OS cannot guarantee the virtual memory map is adjacent, we have to disable this feature. Thank you Yao Jiewen -----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
