lkml.org 
[lkml]   [2015]   [Sep]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 26/26] x86, pkeys: Documentation

* Dave Hansen <dave@sr71.net> 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?

> +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?

Just a quick example: let's assume the kernel has an information leak hole, a way
to read any kernel address and pass that to the kernel attacker. Let's also assume
that the main crypto-keys of the kernel are protected by protection-keys. The code
exposing the information leak will very likely have protection-key protected areas
masked out, so the scope of the information leak is mitigated to a certain degree,
the crypto keys are not readable.

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.

Thanks,

Ingo


\
 
 \ /
  Last update: 2015-09-20 11:01    [W:0.188 / U:0.736 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site