[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jKF089SKyWfMpSqV1M=uhS9j2_kOD+hUekhcX78xEEjPw@mail.gmail.com>
Date: Thu, 4 Jan 2018 16:06:30 -0800
From: Kees Cook <keescook@...gle.com>
To: Dave Hansen <dave.hansen@...ux.intel.com>
Cc: LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
moritz.lipp@...k.tugraz.at,
Daniel Gruss <daniel.gruss@...k.tugraz.at>,
michael.schwarz@...k.tugraz.at, richard.fellner@...dent.tugraz.at,
Andy Lutomirski <luto@...nel.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Hugh Dickins <hughd@...gle.com>
Subject: Re: [PATCH] x86/doc: add PTI description
On Thu, Jan 4, 2018 at 12:54 PM, Dave Hansen
<dave.hansen@...ux.intel.com> wrote:
> [...]
> +For new userspace mappings, the kernel makes the entries in its
> +page tables like normal. The only difference is when the kernel
> +makes entries in the top (PGD) level. In addition to setting the
> +entry in the main kernel PGD, a copy of the entry is made in the
> +userspace page tables' PGD.
It might be worth noting that NX is set in the kernel's view of the
userspace page tables.
> [...]
> +1. Increased Memory Use
> + a. Each process now needs an order-1 PGD instead of order-0.
> + (Consumes 4k per process).
"Consumes an additional 4k per process" ?
> [...]
> + 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?
> [...]
> + 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?
Otherwise, looks good!
Reviewed-by: Kees Cook <keescook@...omium.org>
-Kees
--
Kees Cook
Pixel Security
Powered by blists - more mailing lists