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

Groups > linux.kernel > #1226326 > unrolled thread

[PATCH 26/26] x86, pkeys: Documentation

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [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

#1226326 — [PATCH 26/26] x86, pkeys: Documentation

---

 b/Documentation/x86/protection-keys.txt |   65 ++++++++++++++++++++++++++++++++
 1 file changed, 65 insertions(+)

diff -puN /dev/null Documentation/x86/protection-keys.txt
--- /dev/null	2015-07-13 14:24:11.435656502 -0700
+++ b/Documentation/x86/protection-keys.txt	2015-09-16 09:45:55.874491904 -0700
@@ -0,0 +1,65 @@
+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.
+
+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.
+
+The kernel attempts to make protection keys consistent with the
+behavior of a plain mprotect().  For instance if you do this:
+
+        mprotect(ptr, size, PROT_NONE);
+	something(ptr);
+
+you can expect the same effects with protection keys when doing this:
+
+	mprotect(ptr, size, PROT_READ|PROT_WRITE);
+        set_pkey(ptr, size, 4);
+        wrpkru(0xffffff3f); // access disable pkey 4
+	something(ptr);
+
+That should be true whether something() is a direct access to 'ptr'
+like:
+
+        *ptr = foo;
+
+or when the kernel does the access on the application's behalf like
+with a read():
+
+	read(fd, ptr, 1);
+
+The kernel will send a SIGSEGV in both cases, but si_code will be set
+to SEGV_PKERR when violating protection keys versus SEGV_ACCERR when
+the plain mprotect() permissions are violated.
+
+=========
+
+Changes in v005:
+ * completed "software enforcement of PKEYs"
+ * fixed a ton of bugs
+
+Changes in v004:
+ * bunch of code updates including working signal handling
+
+Changes in v003:
+ * update to new FPU code, and add a bunch of XSAVE patches
+   to the beginning
+
+Changes in v002:
+
+ * make mprotect() actually work
+
+
_
--
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/

[toc] | [next] | [standalone]

#1228849

* 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/

[toc] | [prev] | [next] | [standalone]

#1229015

On 09/20/2015 01:55 AM, Ingo Molnar wrote:
> * 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?

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 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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web