mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@linux.intel.com>
To: Nadav Amit <namit@vmware.com>, linux-kernel@vger.kernel.org
Cc: luto@kernel.org, tglx@linutronix.de, mingo@redhat.com,
	hpa@zytor.com, x86@kernel.org, nadav.amit@gmail.com, w@1wt.eu
Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI
Date: Mon, 15 Jan 2018 11:49:19 -0800	[thread overview]
Message-ID: <57a8fa6b-a1d1-d440-ce13-b1d06d265584@linux.intel.com> (raw)
In-Reply-To: <20180114201306.3554-1-namit@vmware.com>

On 01/14/2018 12:13 PM, Nadav Amit wrote:
> Currently, when page-table isolation is on to prevent the Meltdown bug
> (CVE-2017-5754), CR3 is always loaded on system-call and interrupt.

I think of PTI as being a defense against bad stuff that happens from
the kernel being mapped into the user address space, with Meltdown being
the most obvious "bad" thing.

What you're saying here is that since a 32-bit program can't address the
kernel sitting at a >32-bit address, it does not need to unmap the
kernel.  As Andy pointed out, there are a few holes with that assumption.

IMNHO, any PTI-disabling mechanisms better be rock-solid, and easy to
convince ourselves that they do the right thing.  For instance, the
per-process PTI stuff is going to make the decision quite close to a
capability check, which makes it fairly easy to get right.

If we start disabling PTI willy nilly at points _away_ from the
capability checks (like for 32-bit binaries, say), then it gets really
hard to decide if we are doing the right things.

Also, what's the end goal here?  Run old 32-bit binaries better?  You
want to weaken the security of the whole implementation to do that?
Sounds like a bad tradeoff to me.

  parent reply	other threads:[~2018-01-15 19:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-14 20:13 Nadav Amit
2018-01-15 17:20 ` Andy Lutomirski
2018-01-15 17:42   ` Nadav Amit
2018-01-15 17:45     ` Andy Lutomirski
2018-01-15 17:50       ` Nadav Amit
2018-01-15 18:04         ` Andy Lutomirski
2018-01-15 18:50           ` Nadav Amit
2018-01-15 19:49 ` Dave Hansen [this message]
2018-01-15 19:52   ` Willy Tarreau
2018-01-15 20:09   ` Nadav Amit
2018-01-16  0:41     ` Ingo Molnar
2018-01-16  3:49       ` Nadav Amit
2018-01-20 14:26         ` Ingo Molnar
2018-01-20 16:31           ` 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=57a8fa6b-a1d1-d440-ce13-b1d06d265584@linux.intel.com \
    --to=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=namit@vmware.com \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome