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
next prev parent reply other threads:[~2015-11-07 7:03 UTC|newest]
Thread overview: 26+ 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 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:24 ` Borislav Petkov
2015-11-07 7:03 ` Ingo Molnar [this message]
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:39 ` Ard Biesheuvel
2015-11-08 6:58 ` Kees Cook
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
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=20151107070339.GA6235@gmail.com \
--to=mingo@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=davej@codemonkey.org.uk \
--cc=dvlasenk@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=matt.fleming@intel.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).