On 29 June 2015 at 13:33, Laszlo Ersek <ler...@redhat.com> wrote: > On 06/29/15 12:46, Ard Biesheuvel wrote: >> 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. > > Where / how? Did you enable it in the guest kernel (if that question > makes sense), or in the ArmVirtPkg build? >
No, I enabled it in the ArmVirtPkg. > In the latter, I can only see the PropertiesTableEnable PCD, but (a) it > defaults to TRUE, (b) does it actually control the splitting? > Yes, it does. But it only works if a) you are using a linker script that aligns the data section at 4 KB. Otherwise, you get the runtime error message that you yourself inquired about a couple of weeks ago, about the section alignment being != 4 KB b) EndOfDxe is being signalled correctly So after putting all the pieces in place, the Linux AARCH64 kernel boots, remaps the EFI runtime regions, and then crashes when trying to read the EFI rtc, since the RealTimeClockRuntimeDxe is corrupted due to the fact that its code and data regions are no longer mapped adjacently. -- Ard. >> 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
