From: Dave Hansen <dave.hansen@linux.intel.com>
To: Kees Cook <keescook@google.com>
Cc: LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
moritz.lipp@iaik.tugraz.at,
Daniel Gruss <daniel.gruss@iaik.tugraz.at>,
michael.schwarz@iaik.tugraz.at,
richard.fellner@student.tugraz.at,
Andy Lutomirski <luto@kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH] x86/doc: add PTI description
Date: Thu, 4 Jan 2018 16:21:46 -0800 [thread overview]
Message-ID: <622d362d-d3f2-bb27-6fb2-2334b38c1933@linux.intel.com> (raw)
In-Reply-To: <CAGXu5jKF089SKyWfMpSqV1M=uhS9j2_kOD+hUekhcX78xEEjPw@mail.gmail.com>
On 01/04/2018 04:06 PM, Kees Cook wrote:
>> + d. Process Context IDentifiers (PCID) is a CPU feature that
>> + allows us to skip flushing the entire TLB when switching page
>> + tables. This makes switching the page tables (at context
>> + switch, or kernel entry/exit) cheaper. But, on systems with
>> + PCID support, the context switch code must flush both the user
>> + and kernel entries out of the TLB. The user PCID TLB flush is
>> + deferred until the exit to userspace, minimizing the cost.
>
> Does this mean it's possible to bypass the NX on userspace pages?
I'll clarify this. The write to CR3 happens, but bit 63 gets set to
tell the CPU not to flush the TLB on the CR3 write.
>> [...]
>> + g. On systems without PCID support, each CR3 write flushes
>> + the entire TLB. That means that each syscall, interrupt
>> + or exception flushes the TLB.
>
> Is it worth clarifying this for hardware support of PCID vs INVPCID?
I'll make changes based on the rest of your comments. Thanks for taking
a look!
next prev parent reply other threads:[~2018-01-05 0:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-04 20:54 [PATCH] x86/doc: add PTI description Dave Hansen
2018-01-04 21:46 ` Thomas Gleixner
2018-01-05 0:06 ` Kees Cook
2018-01-05 0:21 ` Dave Hansen [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-12-18 22:04 Dave Hansen
2017-12-19 0:09 ` Randy Dunlap
2017-12-19 1:13 ` Dave Hansen
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=622d362d-d3f2-bb27-6fb2-2334b38c1933@linux.intel.com \
--to=dave.hansen@linux.intel.com \
--cc=daniel.gruss@iaik.tugraz.at \
--cc=hughd@google.com \
--cc=keescook@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=michael.schwarz@iaik.tugraz.at \
--cc=moritz.lipp@iaik.tugraz.at \
--cc=richard.fellner@student.tugraz.at \
--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