From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753865AbbIUEeJ (ORCPT ); Mon, 21 Sep 2015 00:34:09 -0400 Received: from www.sr71.net ([198.145.64.142]:51400 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751610AbbIUEeI (ORCPT ); Mon, 21 Sep 2015 00:34:08 -0400 Subject: Re: [PATCH 26/26] x86, pkeys: Documentation To: Ingo Molnar References: <20150916174903.E112E464@viggo.jf.intel.com> <20150916174913.AF5FEA6D@viggo.jf.intel.com> <20150920085554.GA21906@gmail.com> Cc: x86@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , Andrew Morton , Peter Zijlstra , Andy Lutomirski , Borislav Petkov From: Dave Hansen Message-ID: <55FF88BA.6080006@sr71.net> Date: Sun, 20 Sep 2015 21:34:02 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150920085554.GA21906@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/20/2015 01:55 AM, Ingo Molnar wrote: > * Dave Hansen wrote: >> +Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature >> +which will be found on future Intel CPUs. >> + >> +Memory Protection Keys provides a mechanism for enforcing page-based >> +protections, but without requiring modification of the page tables >> +when an application changes protection domains. It works by >> +dedicating 4 previously ignored bits in each page table entry to a >> +"protection key", giving 16 possible keys. > > Wondering how user-space is supposed to discover the number of protection keys, > is that CPUID leaf based, or hardcoded on the CPU feature bit? The 16 keys are essentially hard-coded from the cpuid bit. >> +There is also a new user-accessible register (PKRU) with two separate >> +bits (Access Disable and Write Disable) for each key. Being a CPU >> +register, PKRU is inherently thread-local, potentially giving each >> +thread a different set of protections from every other thread. >> + >> +There are two new instructions (RDPKRU/WRPKRU) for reading and writing >> +to the new register. The feature is only available in 64-bit mode, >> +even though there is theoretically space in the PAE PTEs. These >> +permissions are enforced on data access only and have no effect on >> +instruction fetches. > > Another question, related to enumeration as well: I'm wondering whether there's > any way for the kernel to allocate a bit or two for its own purposes - such as > protecting crypto keys? Or is the facility fundamentally intended for user-space > use only? No, that's not possible with the current setup. Userspace has complete control over the contents of the PKRU register with unprivileged instructions. So the kernel can not practically protect any of its own data with this. > Similarly, the pmem (persistent memory) driver could employ protection keys to > keep terabytes of data 'masked out' most of the time - protecting data from kernel > space memory corruption bugs. I wish we could do this, but we can not with the current implementation.