Re: [GIT PULL] x86/mm changes for v4.4

[Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

* Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org> wrote:

> On Thu, 05 Nov, at 01:33:10PM, Linus Torvalds wrote:
> > 
> > And if this turns out to be due to EFI wanting those permissions, what should 
> > we do? People have talked about running the EFI callbacks in their own private 
> > page table setup, which sounds like the right idea, but until that actually 
> > *happens*....
> 
> We have separate page tables today, for a few reasons, but mainly it's
> so that we can have an identity mapping of memory present in the
> region usually used by user processes - broken firmware still uses
> those identity mappings even after the kernel tells it they're
> invalid.
> 
> Note that when I say "separate" I'm talking about trampoline_pgd[]
> which is also used by the x86 suspend/resume code.
> 
> However, turns out that the issue with the current scheme is the fact
> that trampoline_pgd[] actually shares a couple of PGD entries with
> swapper_pg_dir as can be seen in setup_real_mode(),
> 
> 
>         trampoline_pgd = (u64 *)__va(real_mode_header->trampoline_pgd);
>         trampoline_pgd[0] = init_level4_pgt[pgd_index(__PAGE_OFFSET)].pgd;
>         trampoline_pgd[511] = init_level4_pgt[511].pgd;
> 
> 
> So when we map the EFI regions in efi_map_regions() we're inserting
> them into swapper_pg_dir also, which is why you're seeing the
> warnings.
> 
> If I remember correctly the rationale for using trampoline_pgd[] was
> that it already did what we wanted (provided the identity mapping) and
> would save us the overhead of maintaining more page tables for no good
> reason. Obviously this entire thread is a good reason.
> 
> I suggest we stop using trampoline_pgd[] (since it has a good reason
> for sharing the kernel mapping PGD entries) and create our own so that
> we can isolate EFI completely.

Ok. Could you please make this fix a priority for upcoming EFI changes?

> For the immediate problem of the warnings spewing forth on all UEFI
> machines, at the very least the config options needs to be disabled by
> default, if not the patch reverted.

We'll certainly flip around the default, but reverting would be shooting
the messenger: the EFI code is endangering everyone else today, and for
no good reason as it appears... so the warning very much served its
purpose in pointing out a valid problem.

Thanks,

	Ingo