linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Ingo Molnar <mingo@kernel.org>
Cc: Nadav Amit <nadav.amit@gmail.com>,
	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>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI
Date: Sat, 20 Jan 2018 17:31:30 +0100	[thread overview]
Message-ID: <20180120163130.GA26410@1wt.eu> (raw)
In-Reply-To: <20180120142627.jttjdsenwsedvle6@gmail.com>

On Sat, Jan 20, 2018 at 03:26:27PM +0100, Ingo Molnar wrote:
> 
> * 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.

Well, I do not agree with this, for the simple reason that the SMEP-like
protection provided by PTI was in fact a byproduct of the Meltdown
mitigation, eventhough quite a valuable one. For me, disabling PTI means
"I want to recover the performance I had on this workload before the PTI
fixes because I value performance over security". By doing it per process
we'll allow users to have both performance for a few processes and
protection (including SMEP-like) for the rest of the system. Their only
other choice will be to completely disable PTI, thus removing all
protection and losing the SMEP emulation.

Best regards,
Willy

      reply	other threads:[~2018-01-20 16:31 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
2018-01-20 16:31           ` Willy Tarreau [this message]

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=20180120163130.GA26410@1wt.eu \
    --to=w@1wt.eu \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --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;
as well as URLs for NNTP newsgroup(s).