On 29 June 2015 at 15:06, Laszlo Ersek <ler...@redhat.com> wrote: > On 06/29/15 14:44, Ard Biesheuvel wrote: >> 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. > > If the SUSE kernel is using a patch for this, then I hope it was at > least *submitted* to lkml / linux-efi? >
Not needed, probably. AArch64 is the only arch that remaps the EFI memory regions with a 64 KB alignment, which is what causes the issue. 'Suse 11 GM' most likely means the x86_64 version. >>> 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. >> > > I agree. If there's a new requirement on the OS or boot loader with > regard to mapping UEFI memmap ranges, that should be spelled out in the > UEFI spec. > > I tried to check, and at the moment the UEFI spec seems neither buggy > nor theoretically impossible to implement in the firmware. If the spec > is deemed complete at this point, then the relocation logic needs > improvement. > Well, it turns out (after looking at the PE/COFF spec), that a section's offset with respect to ImageBase is not expected to change. This means obviously that the relative offset between any two sections is expected to remain the same as well. Whether this would still allow a hack to work around it is anyone's guess: my assessment for AArch64 would be that (since we are using the large model, which makes all external references absolute), it would be possible to move the .data section away from the .text section and reapply the relocations with different adjustment values for each of them. But not a road we want to go down, I suppose. It would be nice if we could use old style mappings with the new style feature enabled: now the PE/COFF images are just spread out over code and data sections, and any information that they belong together is lost. In my opinion (which is offered after the fact, of course), retaining the 'code' region for the entire PE/COFF image, with some annotation that marks it as a PE/COFF .text region followed by a date region would have been friendlier to older OSes. That still doesn't solve the problem how to pass the information about which subregion can be mapped RO and which XP -- Ard. > I did see Matt's question in the mantis ticket > <https://mantis.uefi.org/mantis/view.php?id=1224>, and Vincent's answer > that a new whitepaper would be released. Still that doesn't substitute > for clarity in the spec, or more complete implementation, in my opinion. > > In any case, for OVMF, I think we'll need a small patch that disables > this feature (if for nothing else, then to quell the noisy warnings > about "the section alignment being != 4 KB"). I'm adding that to my > queue (but anyone please feel free to do it while I'm offline). > > Two more questions: > - what's the reason for "PropertiesTableEnable" being just a boolean > PCD, not a feature one? Is it expected to be set dynamically (perhaps > based on processor features)? > - shouldn't it be called *Pcd*PropertiesTableEnable? > > Thanks > Laszlo ------------------------------------------------------------------------------ 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
