From: Ingo Molnar <mingo@kernel.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Willy Tarreau <w@1wt.eu>, Borislav Petkov <bp@alien8.de>,
LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
Brian Gerst <brgerst@gmail.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Josh Poimboeuf <jpoimboe@redhat.com>,
"H. Peter Anvin" <hpa@zytor.com>,
Kees Cook <keescook@chromium.org>
Subject: Re: [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET_NOPTI to enable/disable PTI
Date: Wed, 10 Jan 2018 08:13:32 +0100 [thread overview]
Message-ID: <20180110071332.clesa7yfdnpgzmph@gmail.com> (raw)
In-Reply-To: <CALCETrU_Qt+0k4GO2qp=9D7h5czp0QkY=D9Y4AUfs9yzpNHswQ@mail.gmail.com>
* Andy Lutomirski <luto@kernel.org> wrote:
> On Tue, Jan 9, 2018 at 6:54 AM, Willy Tarreau <w@1wt.eu> wrote:
> > On Tue, Jan 09, 2018 at 03:51:57PM +0100, Borislav Petkov wrote:
> >> On Tue, Jan 09, 2018 at 03:36:53PM +0100, Willy Tarreau wrote:
> >> > I see and am not particularly against this, but what use case do you
> >> > have in mind precisely ? I doubt it's just saving a few tens of bytes,
> >> > so probably you're more concerned about the potential risks this opens ?
> >> > But given we only allow this for CAP_SYS_RAWIO and these ones already
> >> > have access to /dev/mem and many other things, don't you think there
> >> > are much easier ways to dump kernel memory in this case than trying to
> >> > inject some meltdown code into the victim process ? Or maybe you have
> >> > other cases in mind that I'm not seeing.
> >>
> >> I'd like this to be config-controllable so that distros can make the
> >> decision whether/if they want to support the whole per-mm thing.
> >
> > OK.
> >
> >> Also, if CAP_SYS_RAWIO is going to protect, please make the
> >> ARCH_GET_NOPTI variant check it too.
> >
> > Interestingly I removed the check consecutive to the discussions. But
> > I think I'll simply remove the whole ARCH_GET_NOPTI as it has no real
> > value beyond initial development.
> >
>
> I've thought about this a bit more. Here are my thoughts:
>
> 1. I don't like it being per-mm. I think it should be a per-thread
> control so that a program can have a thread with PTI that runs
> less-trusted JavaScript and other network threads with PTI off.
> Obviously we lose NX protection mm-wide if any threads have PTI off.
> I think the way to implement this is:
Btw., the "NX protection", the NX bit set in the PTI kernel pagetables for the
user range really just matters for non-SMEP hardware, right? On SMEP a CPU in
kernel privilege mode cannot execute user pages, i.e. the fact that it's user
pages is already NX, guaranteed by the CPU.
And note how there's a happy circumstance for users, regarding SMEP and PTI NX:
- All Intel desktop/server CPUs currently sold and those built in the last ~3
years have SMEP enabled already, so are not affected.
- AMD CPUs don't have PTI enabled, so they already don't have NX for their user
pages - no change in behavior.
I.e.: non-issue and not a real constraint on the flexibility of this ABI, AFAICS -
it's "only" an implementational matter.
Thanks,
Ingo
next prev parent reply other threads:[~2018-01-10 7:13 UTC|newest]
Thread overview: 103+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-09 12:56 [RFC PATCH v2 0/6] Per process PTI activation Willy Tarreau
2018-01-09 12:56 ` [RFC PATCH v2 1/6] x86/mm: add a pti_disable entry in mm_context_t Willy Tarreau
2018-01-09 12:56 ` [RFC PATCH v2 2/6] x86/arch_prctl: add ARCH_GET_NOPTI and ARCH_SET_NOPTI to enable/disable PTI Willy Tarreau
2018-01-09 14:17 ` Borislav Petkov
2018-01-09 14:36 ` Willy Tarreau
2018-01-09 14:51 ` Borislav Petkov
2018-01-09 14:54 ` Willy Tarreau
2018-01-09 21:26 ` Andy Lutomirski
2018-01-09 21:29 ` Borislav Petkov
2018-01-09 21:32 ` Willy Tarreau
2018-01-09 21:46 ` Borislav Petkov
2018-01-09 22:06 ` Willy Tarreau
2018-01-09 22:20 ` Borislav Petkov
2018-01-09 22:29 ` Dave Hansen
2018-01-09 22:40 ` Willy Tarreau
2018-01-10 14:42 ` Borislav Petkov
2018-01-10 15:39 ` Willy Tarreau
2018-01-10 16:09 ` Borislav Petkov
2018-01-10 16:19 ` Willy Tarreau
2018-01-10 17:28 ` Borislav Petkov
2018-01-10 7:31 ` Ingo Molnar
2018-01-10 7:37 ` Willy Tarreau
2018-01-10 7:59 ` Ingo Molnar
2018-01-09 23:53 ` Andy Lutomirski
2018-01-10 4:25 ` Willy Tarreau
2018-01-10 7:25 ` Ingo Molnar
2018-01-10 14:45 ` Borislav Petkov
2018-01-10 15:43 ` Willy Tarreau
2018-01-10 15:45 ` Ingo Molnar
2018-01-09 21:34 ` Kees Cook
2018-01-09 21:41 ` Willy Tarreau
2018-01-09 21:50 ` Kees Cook
2018-01-09 22:03 ` Willy Tarreau
2018-01-10 7:13 ` Ingo Molnar [this message]
2018-01-12 15:03 ` David Laight
2018-01-12 15:06 ` Willy Tarreau
2018-01-09 12:56 ` [RFC PATCH v2 3/6] x86/pti: add a per-cpu variable pti_disable Willy Tarreau
2018-01-10 7:19 ` Ingo Molnar
2018-01-10 7:29 ` Willy Tarreau
2018-01-10 8:01 ` Ingo Molnar
2018-01-10 8:50 ` Willy Tarreau
2018-01-10 8:59 ` Ingo Molnar
2018-01-10 9:00 ` Willy Tarreau
2018-01-09 12:56 ` [RFC PATCH v2 4/6] x86/pti: don't mark the user PGD with _PAGE_NX Willy Tarreau
2018-01-09 12:56 ` [RFC PATCH v2 5/6] x86/entry/pti: avoid setting CR3 when it's already correct Willy Tarreau
2018-01-10 7:16 ` Ingo Molnar
2018-01-10 7:18 ` Willy Tarreau
2018-01-10 20:29 ` Dave Hansen
2018-01-11 6:46 ` Willy Tarreau
2018-01-09 12:56 ` [RFC PATCH v2 6/6] x86/entry/pti: don't switch PGD on when pti_disable is set Willy Tarreau
2018-01-10 7:15 ` Ingo Molnar
2018-01-10 7:23 ` Willy Tarreau
2018-01-10 8:22 ` Peter Zijlstra
2018-01-10 9:11 ` Willy Tarreau
2018-01-10 19:21 ` Andy Lutomirski
2018-01-10 19:39 ` Willy Tarreau
2018-01-10 19:44 ` Andy Lutomirski
2018-01-10 19:50 ` Linus Torvalds
2018-01-10 20:04 ` Andy Lutomirski
2018-01-11 6:42 ` Willy Tarreau
2018-01-11 15:29 ` Dave Hansen
2018-01-11 15:44 ` Willy Tarreau
2018-01-11 15:51 ` Dave Hansen
2018-01-11 17:02 ` Andy Lutomirski
2018-01-11 18:21 ` Alexei Starovoitov
2018-01-11 18:30 ` Dave Hansen
2018-01-11 18:32 ` Josh Poimboeuf
2018-01-11 18:36 ` Linus Torvalds
2018-01-11 18:38 ` Dave Hansen
2018-01-11 18:51 ` Linus Torvalds
2018-01-11 18:57 ` Dave Hansen
2018-01-11 19:05 ` Josh Poimboeuf
2018-01-11 19:07 ` Borislav Petkov
2018-01-11 19:17 ` Dave Hansen
2018-01-11 19:19 ` Olivier Galibert
2018-01-11 19:26 ` Josh Poimboeuf
2018-01-11 19:34 ` Alan Cox
2018-01-11 21:23 ` Willy Tarreau
2018-01-11 21:28 ` Linus Torvalds
2018-01-11 22:06 ` Willy Tarreau
2018-01-12 16:37 ` David Laight
2018-01-11 19:12 ` Linus Torvalds
2018-01-11 19:38 ` Alexei Starovoitov
2018-01-11 19:11 ` Willy Tarreau
2018-01-11 20:00 ` Dave Hansen
2018-01-11 17:09 ` Andy Lutomirski
2018-01-11 17:40 ` Willy Tarreau
2018-01-11 17:53 ` Andy Lutomirski
2018-01-11 18:05 ` Willy Tarreau
2018-01-11 18:15 ` Dave Hansen
2018-01-11 18:31 ` Linus Torvalds
2018-01-11 18:25 ` Linus Torvalds
2018-01-11 18:26 ` Linus Torvalds
2018-01-11 19:33 ` Andy Lutomirski
2018-01-12 20:22 ` Ingo Molnar
2018-01-12 21:18 ` Andy Lutomirski
2018-01-12 21:54 ` Willy Tarreau
2018-01-11 21:59 ` Willy Tarreau
2018-01-12 16:27 ` David Laight
2018-01-12 17:55 ` Linus Torvalds
2018-01-12 19:36 ` Willy Tarreau
2018-01-11 18:35 ` Dave Hansen
2018-01-11 21:49 ` Willy Tarreau
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=20180110071332.clesa7yfdnpgzmph@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=brgerst@gmail.com \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=w@1wt.eu \
--cc=x86@kernel.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.