On Fri, 13 Nov, at 08:42:54AM, Linus Torvalds wrote: > On Fri, Nov 13, 2015 at 1:29 AM, Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote: > > On Fri, 13 Nov, at 10:22:10AM, Ingo Molnar wrote: > > > > You've snipped the patch hunk that gives the address range used, > > I'm actually wondering if we should strive to make the UEFI stuff more > like a user process, and just map the UEFI mappings in low memory in > that magic UEFI address space. We map things in the user address space now but only for the purposes of having an identity mapping, for the reasons that I mentioned previously: bust firmware accesses and for the SetVirtaulAddressMap() call [1]. Importantly, the kernel does not access the identity mapping directly. So if we were to repurpose the user address space it would make sense to just have the identity mapping be the one and only mapping. However, going through the identity addresses to invoke EFI runtime services is known to break some Apple Macs. It's probably worth revisiting this issue, because I don't have any further details. Having a separate mapping in the user address space that isn't the identity mapping is also possible of course. > We won't be able to run those things *as* user space, since I assume > the code will want to do a lot of kernely things, but shouldn't we aim > to make it look as much like that as possible? Maybe some day we could > even strive to run it in some controlled environment (ie user space > with fixups, virtual machine, whatever), but even if we never get > there it sounds like a potentially good idea to try to set up the > mappings to move in that direction.. It would be interesting to see how far we could push this, say, using SMAP/SMEP to further isolate what kernel pieces the firmware can touch. It's not about security guarantees since most of the firmware functionality is implemented in SMM today for x86, but it does go some way towards providing protection from unintended accesses. > No big hurry, and maybe there are good reasons not to go that way. The > first step is indeed just to get rid of the WX mappings in the normal > kernel page tables. I think it's worth exploring. [1] Oh, and also for the EFI mixed mode code (running 64-bit kernels on 32-bit EFI), but less people tend to care about that ;-) -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
