On Wed, Oct 14, 2015 at 8:18 AM, Ingo Molnar <mi...@kernel.org> wrote: > > * Matt Fleming <m...@codeblueprint.co.uk> wrote: > >> On Mon, 12 Oct, at 04:17:54PM, Ingo Molnar wrote: >> > >> > * Matt Fleming <m...@codeblueprint.co.uk> 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-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
