From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759643AbdLSBNn (ORCPT ); Mon, 18 Dec 2017 20:13:43 -0500 Received: from mga06.intel.com ([134.134.136.31]:62634 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752943AbdLSBNm (ORCPT ); Mon, 18 Dec 2017 20:13:42 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,423,1508828400"; d="scan'208";a="3899929" Subject: Re: [PATCH] x86/doc: add PTI description To: Randy Dunlap , linux-kernel@vger.kernel.org References: <20171218220413.67C44542@viggo.jf.intel.com> <990a6023-14df-f9d8-d018-9174e4876d88@infradead.org> Cc: x86@kernel.org, moritz.lipp@iaik.tugraz.at, daniel.gruss@iaik.tugraz.at, michael.schwarz@iaik.tugraz.at, richard.fellner@student.tugraz.at, luto@kernel.org, torvalds@linux-foundation.org, keescook@google.com, hughd@google.com From: Dave Hansen Message-ID: <3a092361-58b8-9c99-01e6-a0bab01ac6b0@linux.intel.com> Date: Mon, 18 Dec 2017 17:13:35 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <990a6023-14df-f9d8-d018-9174e4876d88@infradead.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org >> +copy of the page tables which are used only when running userspace >> +applications. When the kernel is entered via syscalls, interrupts or >> +exceptions, page tables are switched to the full "kernel" copy. When >> +the system switches back to user mode, the user copy is used again. > > Uh, can userspace on one CPU attempt to observe kernelspace on the processor > that is running kernel code? I haven't read any of the published papers, > so maybe I'm out in the woods here... The paper basically shows how unprivileged userspace can figure out where the kernel is located in memory, despite that location being random. It's not observing another process or the kernel *running*. It's just finding where it *is*. >> +When PTI is enabled, the kernel manages two sets of page >> +tables. The first copy is very similar to what would be present >> +for a kernel without PTI. This includes a complete mapping of >> +userspace that the kernel can use for things like copy_to_user(). >> + >> +The userspace copy is used when running userspace and mirrors the >> +mapping of userspace present in the kernel copy. It maps a only >> +the kernel data needed to enter and exit the kernel. This data >> +is entirely contained in the 'struct cpu_entry_area' structure >> +which is placed in the fixmap and thus each CPU's copy of the >> +area has a compile-time-fixed virtual address. > > Is that last sentence supposed to be a good thing? Doesn't sound it > to me... It's a good thing, generally. It makes it easy for a CPU to locate *its* data. >> + g. On systems without PCID support, each CR3 write flushes >> + the entire TLB. That means that each syscall, interrupt >> + or exception flushes the TLB. > > Does this imply that PTI is best suited to CPUs that have PCID? Yes, the performance properties are much less onerous on systems with PCID.