From: Willy Tarreau <w@1wt.eu>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Nadav Amit <namit@vmware.com>,
linux-kernel@vger.kernel.org, luto@kernel.org,
tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, nadav.amit@gmail.com
Subject: Re: [RFC] x86: Avoid CR3 load on compatibility mode with PTI
Date: Mon, 15 Jan 2018 20:52:52 +0100 [thread overview]
Message-ID: <20180115195252.GH7804@1wt.eu> (raw)
In-Reply-To: <57a8fa6b-a1d1-d440-ce13-b1d06d265584@linux.intel.com>
On Mon, Jan 15, 2018 at 11:49:19AM -0800, Dave Hansen wrote:
> 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.
In fact I understand it differently, which is that by running 32-bit,
he can recover the original performance without sacrifying security.
It's not that bad actually when you think about it since the vast
majority of performance-sensitive software doesn't need to access
even one GB of data.
Willy
next prev parent reply other threads:[~2018-01-15 19:53 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 [this message]
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=20180115195252.GH7804@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@redhat.com \
--cc=nadav.amit@gmail.com \
--cc=namit@vmware.com \
--cc=tglx@linutronix.de \
--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.