[PATCH 00/12] [RFC] x86: Memory Protection Keys

[Dave Hansen]

This is a big, fat RFC.  This code is going to be unrunable to
anyone outside of Intel.  But, this patch set has user interface
implications because we need to pass the protection key in to
the kernel somehow.

At this point, I would especially appreciate feedback on how
we should do that.  I've taken the most expedient approach for
this first attempt, especially since we piggyback on existing
syscalls here.

There is a lot of work left to do here.  Mainly, we need to
ensure that when we are walking the page tables in software
that we obey protection keys when at all possible.  This is
going to mean a lot of audits of the page table walking code,
although some of it like access_process_vm() we can probably
safely ignore.

This set is also available here:

	git://git.kernel.org/pub/scm/linux/kernel/git/daveh/x86-pkeys.git pkeys-v001

== FEATURE OVERVIEW ==

Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU
feature which will be found in future Intel CPUs.  The work here
was done with the aid of simulators.

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.

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.

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