On 09/20/2015 01:55 AM, Ingo Molnar wrote: > * Dave Hansen <dave@xxxxxxxx> 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>