mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Nadav Amit <nadav.amit@gmail.com>,
	Dave Hansen <dave.hansen@linux.intel.com>
Cc: Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Andy Lutomirski <luto@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>, Willy Tarreau <w@1wt.eu>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode
Date: Fri, 16 Feb 2018 00:45:35 +0000	[thread overview]
Message-ID: <f0fc93ca-ba1d-2570-5d79-0c02ee388f9d@citrix.com> (raw)
In-Reply-To: <91CEEFA7-86C8-4731-BC7E-6AF5CC3A1BA4@gmail.com>

On 16/02/2018 00:25, Nadav Amit wrote:
> Dave Hansen <dave.hansen@linux.intel.com> wrote:
>
>> On 02/15/2018 08:35 AM, Nadav Amit wrote:
>>> I removed the PTI disabling while SMEP is unsupported, although I
>>> must admit I did not fully understand why it is required.
>> Do you mean you don't fully understand how PTI gives SMEP-like behavior
>> on non-SMEP hardware?
> No. I understand how it provide SMEP-like behavior, and I understand the value
> of SMEP by itself.
>
> However, I do not understand why SMEP-like protection is required to protect
> processes that run in compatibility-mode from Meltdown/Spectre attacks. As
> far as I understand, the process should not be able to manipulate the kernel
> to execute code in the low 4GB.

Being 32bit is itself sufficient protection against Meltdown (as long as
there nothing interesting of the kernels mapped below the 4G boundary).

However, a 32bit compatibility process try to attack with Spectre/SP2 to
redirect speculation back into userspace, at which point (if successful)
the pipeline will be speculating in 64bit mode, and Meltdown is back on
the table.  SMEP will block this attack vector, irrespective of other
SP2 defences the kernel may employ, but a fully SP2-defended kernel
doesn't require SMEP to be safe in this case.

~Andrew

  parent reply	other threads:[~2018-02-16  0:45 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-15 16:35 Nadav Amit
2018-02-15 16:35 ` [PATCH RFC v2 1/6] x86: Skip PTI when disable indication is set Nadav Amit
2018-02-15 18:10   ` Dave Hansen
2018-02-15 19:51   ` Andy Lutomirski
2018-02-15 20:51     ` Nadav Amit
2018-02-15 23:35       ` Andy Lutomirski
2018-02-15 16:35 ` [PATCH RFC v2 2/6] x86: Save pti_disable for each mm_context Nadav Amit
2018-02-15 16:35 ` [PATCH RFC v2 3/6] x86: Switching page-table isolation Nadav Amit
2018-02-15 16:36 ` [PATCH RFC v2 4/6] x86: Disable PTI on compatibility mode Nadav Amit
2018-02-15 20:02   ` Andy Lutomirski
2018-02-15 20:58     ` Nadav Amit
2018-02-15 23:29       ` Andy Lutomirski
2018-02-16  0:08         ` Linus Torvalds
2018-02-16  0:22           ` Nadav Amit
2018-02-16  0:42             ` Linus Torvalds
2018-02-16  3:03               ` Andy Lutomirski
2018-02-16  4:55                 ` Nadav Amit
2018-02-16  0:35           ` Andrew Cooper
2018-02-16 15:20           ` Andy Lutomirski
2018-02-16  7:11         ` Cyrill Gorcunov
2018-02-16 22:07           ` Dmitry Safonov
2018-02-16 22:11             ` Nadav Amit
2018-02-16 16:25     ` Dmitry Safonov
2018-02-15 16:36 ` [PATCH RFC v2 5/6] x86: Use global pages when PTI is disabled Nadav Amit
2018-02-15 16:54   ` Dave Hansen
2018-02-15 17:36     ` Nadav Amit
2018-02-15 17:47     ` Nadav Amit
2018-02-15 18:08       ` Dave Hansen
2018-02-15 19:53   ` Andy Lutomirski
2018-02-15 20:32     ` Dave Hansen
2018-02-15 20:45       ` Nadav Amit
2018-02-15 16:36 ` [PATCH RFC v2 6/6] selftest: x86: test using CS64 on compatibility-mode Nadav Amit
2018-02-16  0:21 ` [PATCH RFC v2 0/6] x86: Disabling PTI in compatibility mode Dave Hansen
2018-02-16  0:25   ` Nadav Amit
2018-02-16  0:42     ` Dave Hansen
2018-02-16  0:48       ` Nadav Amit
2018-02-16  0:45     ` Andrew Cooper [this message]
2018-02-16  0:51       ` Nadav Amit
2018-02-16  1:04         ` Andrew Cooper
2018-02-16  3:05         ` Andy Lutomirski

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=f0fc93ca-ba1d-2570-5d79-0c02ee388f9d@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=peterz@infradead.org \
    --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

all inboxes | Powered by JetHome®