On Wed, Oct 14, 2015 at 8:18 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote: > >> On Mon, 12 Oct, at 04:17:54PM, Ingo Molnar wrote: >> > >> > * Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> wrote: >> > >> > > On Mon, 12 Oct, at 02:49:36PM, Ingo Molnar wrote: >> > > > >> > > > >> > > > So why not unmap them after bootup? Is there any reason to call into EFI code >> > > > while the system is up and running? >> > > >> > > That's where the runtime services code lives. So if you want things like EFI >> > > variables (used by the distro installer, among other things) you need to map the >> > > runtime regions. >> > >> > So EFI variables could be queried during bootup and saved on the Linux side. >> >> Right, we could do that, but then we wouldn't be able to support >> creation/updating variables at runtime, such as when you install a >> distribution for the first time, or want to boot a new kernel filename >> directly from the firmware without a boot loader (and need to modify >> the BootXXXX variables). > > Do we know the precise position and address range of these variables? > > We could map them writable (but not executable), and the rest executable (but not > writable). > > That raises the question whether the same physical page ever mixes variables and > actual code - but the hope would be that it's suffiently page granular for this to > work. Can we just unmap these things until someone tries to do an EFI call, and then unmap them again after the call returns? We already switch pgds for EFI IIRC. --Andy -- 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
