Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1228849

Re: [PATCH 26/26] x86, pkeys: Documentation

Show all headers | View raw

* 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

[PATCH 26/26] x86, pkeys: Documentation Dave Hansen <dave@sr71.net> - 2015-09-16 19:50 +0200
  Re: [PATCH 26/26] x86, pkeys: Documentation Ingo Molnar <mingo@kernel.org> - 2015-09-20 11:00 +0200
    Re: [PATCH 26/26] x86, pkeys: Documentation Dave Hansen <dave@sr71.net> - 2015-09-21 06:40 +0200

csiph-web