On Wed, 30 Jan 2019 at 19:19, Will Deacon <will.deacon@xxxxxxx> wrote: > > Hi Ard, > Hi Will, > On Sat, Jan 26, 2019 at 11:22:07AM +0100, Ard Biesheuvel wrote: > > The UEFI spec revision 2.7 errata A section 8.4 has the following to > > say about the virtual memory runtime services: > > > > "This section contains function definitions for the virtual memory > > support that may be optionally used by an operating system at runtime. > > If an operating system chooses to make EFI runtime service calls in a > > virtual addressing mode instead of the flat physical mode, then the > > operating system must use the services in this section to switch the > > EFI runtime services from flat physical addressing to virtual > > addressing." > > I should probably go RTFM, but what does UEFI say about the attributes of > "flat physical addressing"? The wording above implies to me that it should > act as though the stage-1 MMU is disabled because it's described as an > alternative to virtual addressing. > No. Flat physical addressing applies to the translation, not to the memory attributes. The UEFI spec is pretty detailed when it comes to how the MMU should be configured and which memory attributes should be used while running in the firmware, and while running under the OS, and that is orthogonal. > If we move in a direction where we avoid calling SetVirtualAddressMap() by > default on arm64, isn't there a real threat that this firmware call will no > longer be validated? Do we need to worry about that? > Yes. From a validation pov, it is useful to have both options, since optional functionality should work as specified, but it should also be truly optional, and with this change, we can at least validate that. Whether this will ever become the default or not is something we can debate at a later date. > Finally, Bjorn said that SDM850 is unbootable without this change. Why is > that? > sdm835 and sdm850 are used in Windows on ARM laptops, and Windows behaves differently in this regard. The main issue is that the virtual mapping that Windows installs (which is a kernel mapping) is already active when it makes the call to SetVirtualAddressMap(), which means drivers can get away with accessing both the old and the new mapping in the context of that call. On Linux, the new VA mapping is not mapped yet, and so the code crashes. Another problem is that the PE/COFF relocation processing requires that the code sections are mapped read-write after ExitBootServices(), and the QC firmware is relying on Windows to clear the r/o permissions, rather than clear the r/o bits itself.
