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

From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Stephen Smalley <sds@tycho.nsa.gov>,
	Matt Fleming <matt.fleming@intel.com>,
	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>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [GIT PULL] x86/mm changes for v4.4
Date: Sat, 7 Nov 2015 08:03:39 +0100	[thread overview]
Message-ID: <20151107070339.GA6235@gmail.com> (raw)
In-Reply-To: <CALCETrU2dn4TEj_2QiCPy4Mjw6hCbB84k1RnPzx7sLNygj4D5Q@mail.gmail.com>

* Andy Lutomirski <luto@amacapital.net> wrote:

> On Thu, Nov 5, 2015 at 10:55 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> >> On Wed, Nov 4, 2015 at 6:17 PM, Dave Jones <davej@codemonkey.org.uk> wrote:
> >> > On Wed, Nov 04, 2015 at 05:31:59PM -0800, Linus Torvalds wrote:
> >> >  >
> >> >  > I don't have that later debug output at all. Presumably some config difference.
> >> >
> >> > CONFIG_X86_PTDUMP_CORE iirc.
> >>
> >> No, I have that. I suspect CONFIG_EFI_PGT_DUMP instead.
> >>
> >> Anyway, as it stands now, I think the CONFIG_DEBUG_WX option should
> >> not default to 'y' unless it is made more useful if it actually
> >> triggers. Ingo?
> >
> > Yeah, agreed absolutely.
> >
> > So this is a bit sad because RWX pages are a real problem in practice, especially
> > since the EFI addresses are well predictable, but generating a warning without
> > being able to fix it quickly is counterproductive as well, as it only annoys
> > people and makes them turn off the option. (Which we could do as well to begin
> > with, without the annoyance factor...)
> >
> > So the plan would be:
> >
> >  1) Make it default-n.
> >
> >  2) We should try to further improve the messages to make it easier to determine
> >     what's wrong. We _do_ try to output symbolic information in the warning, to
> >     make it easier to find buggy mappings, but these are not standard kernel
> >     mappings. So I think we need an e820 mappings based semi-symbolic printout of
> >     bad addresses - maybe even correlate it with the MMIO resource tree.
> >
> >  3) We should fix the EFI permission problem without relying on the firmware: it
> >     appears we could just mark everything R-X optimistically, and if a write fault
> >     happens (it's pretty rare in fact, only triggers when we write to an EFI
> >     variable and so), we can mark the faulting page RW- on the fly, because it
> >     appears that writable EFI sections, while not enumerated very well in 'old'
> >     firmware, are still supposed to be page granular. (Even 'new' firmware I
> >     wouldn't automatically trust to get the enumeration right...)
> 
> I think it was Borislav who pointed out that this idea, which might
> have been mine, is a bit silly.  Why not just skip mapping the EFI
> stuff in the init_pgd entirely and only map it in the EFI pgd?
> 
> We'll have RWX stuff in the EFI pgd, but so what?  If we're exposing
> anything that runs with the EFI pgd loaded to untrusted input, I think
> we've already lost.

That's certainly true, I was simply confused about the life time of these 
mappings: I assumed they have to stay around. If they are meant to be and are 
partly temporary today already, we should go the whole mile and make that really 
so, because _today_ the mappings are permanent, so this is a real problem ...

Thanks,

	Ingo