All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Dave Jones <davej@codemonkey.org.uk>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, Borislav Petkov <bp@alien8.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Lutomirski <luto@kernel.org>,
	Denys Vlasenko <dvlasenk@redhat.com>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	linux-efi@vger.kernel.org
Subject: Re: [GIT PULL] x86/mm changes for v4.4
Date: Sat, 7 Nov 2015 10:03:28 +0000	[thread overview]
Message-ID: <20151107100328.GB2387@codeblueprint.co.uk> (raw)
In-Reply-To: <20151107070554.GB6235@gmail.com>

On Sat, 07 Nov, at 08:05:54AM, Ingo Molnar wrote:
> 
> * Matt Fleming <matt@codeblueprint.co.uk> 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?

Yep, I'll get on it.

WARNING: multiple messages have this Message-ID (diff)
From: Matt Fleming <matt-mF/unelCI9GS6iBeEJttW/XRex20P6io@public.gmane.org>
To: Ingo Molnar <mingo-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Linus Torvalds
	<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Dave Jones
	<davej-rdkfGonbjUTCLXcRTR1eJlpr/1R2p/CL@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Thomas Gleixner <tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>,
	"H. Peter Anvin" <hpa-YMNOUZJC4hwAvxtiuMwx3w@public.gmane.org>,
	Borislav Petkov <bp-Gina5bIWoIWzQB+pC5nmwQ@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Andy Lutomirski <luto-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Denys Vlasenko <dvlasenk-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Stephen Smalley <sds-+05T5uksL2qpZYMLLGbcSA@public.gmane.org>,
	linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [GIT PULL] x86/mm changes for v4.4
Date: Sat, 7 Nov 2015 10:03:28 +0000	[thread overview]
Message-ID: <20151107100328.GB2387@codeblueprint.co.uk> (raw)
In-Reply-To: <20151107070554.GB6235-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>

On Sat, 07 Nov, at 08:05:54AM, Ingo Molnar wrote:
> 
> * 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?

Yep, I'll get on it.

  reply	other threads:[~2015-11-07 10:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-03 11:16 [GIT PULL] x86/mm changes for v4.4 Ingo Molnar
2015-11-04 19:26 ` Linus Torvalds
2015-11-04 23:39   ` Dave Jones
2015-11-05  1:31     ` Linus Torvalds
2015-11-05  2:17       ` Dave Jones
2015-11-05 21:27         ` Linus Torvalds
2015-11-05 21:33           ` Linus Torvalds
2015-11-06 11:39             ` Matt Fleming
2015-11-07  7:05               ` Ingo Molnar
2015-11-07  7:05                 ` Ingo Molnar
2015-11-07 10:03                 ` Matt Fleming [this message]
2015-11-07 10:03                   ` Matt Fleming
2015-11-05 22:04           ` Linus Torvalds
2015-11-05 22:27             ` Borislav Petkov
2015-11-06  6:55           ` Ingo Molnar
2015-11-06  7:05             ` Andy Lutomirski
2015-11-06 13:09               ` Matt Fleming
2015-11-06 13:09                 ` Matt Fleming
2015-11-06 13:24                 ` Borislav Petkov
2015-11-06 13:24                   ` Borislav Petkov
2015-11-07  7:03               ` Ingo Molnar
2015-11-06  7:44             ` Ingo Molnar
2015-11-06 12:39             ` Matt Fleming
2015-11-07  7:09               ` Ingo Molnar
2015-11-07  7:09                 ` Ingo Molnar
2015-11-07  7:39                 ` Ard Biesheuvel
2015-11-08  6:58                   ` Kees Cook
2015-11-08  7:55                     ` Ard Biesheuvel
2015-11-08  7:55                       ` Ard Biesheuvel
2015-11-09 21:08                       ` Kees Cook
2015-11-10  7:08                         ` Ard Biesheuvel
2015-11-10 20:11                           ` Kees Cook
2015-11-10 20:11                             ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151107100328.GB2387@codeblueprint.co.uk \
    --to=matt@codeblueprint.co.uk \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=davej@codemonkey.org.uk \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=sds@tycho.nsa.gov \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.