All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	the arch/x86 maintainers <x86@kernel.org>,
	w@1wt.eu, Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI
Date: Sat, 20 Jan 2018 15:26:27 +0100	[thread overview]
Message-ID: <20180120142627.jttjdsenwsedvle6@gmail.com> (raw)
In-Reply-To: <5D6CD440-B20F-4ABF-8B02-EE87205B661D@gmail.com>


* Nadav Amit <nadav.amit@gmail.com> wrote:

> > So we are trading a 5-15% slowdown (PTI) for another 5-15% slowdown, plus we 
> > are losing the soft-SMEP feature on older CPUs that PTI enables, which is a 
> > pretty powerful mitigation technique.
> 
> This soft-SMEP can be kept by keeping PTI if SMEP is unsupported. Although we 
> trade slowdowns, they are different ones, which allows the user to make his best 
> decision.

Indeed, not allowing PTI to be disabled if SMEP is unavailable might be a 
solution.

> > Yes, I suspect in some (maybe many) cases it would be a speedup, but I really 
> > don't like the underlying assumptions and tradeoffs here. (Not that I like any 
> > of this whole Meltdown debacle TBH.)
> 
> To make sure that I understand correctly - the assumptions are that disabling 
> PTI on compatibility mode would: (1) Benefit some workloads; (2) Be useful, even 
> if we only consider CPUs with SMEP; and (3) Secure.
> 
> Under these assumptions, the tradeoff is slightly greater code complexity for 
> considerably better performance of 32-bit code; in some common cases this makes 
> 32-bit code to perform significantly better than 64-bit code.
> 
> Am I missing something? My main concern was initially security, but so far from 
> your aggregated feedback I did not see something concrete which cannot 
> relatively easily be addressed.

Yes, I suppose.

Thanks,

	Ingo

  reply	other threads:[~2018-01-20 14:26 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-14 20:13 [RFC] x86: Avoid CR3 load on compatibility mode with PTI 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
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 [this message]
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=20180120142627.jttjdsenwsedvle6@gmail.com \
    --to=mingo@kernel.org \
    --cc=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=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.