[PATCH 0/5] [RFCv5] add manpages for Memory Protection Keys

[PATCH 0/5] [RFCv5] add manpages for Memory Protection Keys

[Dave Hansen]

From: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

Changes from v4:
 * Remove references to pkey_get/pkey_set since those were
   removed from the code that got merged
 * Updated example code to stop using  pkey_get/set

Changes from v3:
 * Split patches up, one per manpage.
 * Started new sentences on new lines.
 * Added description of default key to pkey.7
 * reindented and fixed up sys_ in example code, s/err/status/,
   also removed assert()s.
 * Various other fixes in response to Michael's review

Changes from v2:
 * clarified that calling pkey_free() on a pkey in use by
   a mapping is bad.

--

Memory Protection Keys for User pages is an Intel CPU feature
which will first appear on Skylake Servers, but will also be
supported on future non-server parts (there is also a QEMU
implementation).  It provides a mechanism for enforcing
page-based protections, but without requiring modification of the
page tables when an application wishes to change permissions.

I have propsed adding three new system calls to support this feature.
The three calls are distributed across two man-pages (one existing
and one new), plus a new pkey(7) page which serves as a general
overview of the feature with example code.

The system calls for this feature are in the -tip tree currently
and are expected to be merged for 4.9.  I will submit the final
versions of these man-pages once the 4.9 kernel has been released.

The latest version of the code can be found here, in addition to
in the -tip tree and -next.

    http://git.kernel.org/cgit/linux/kernel/git/daveh/x86-pkeys.git/

Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/5] pkey.7: New page with overview of Memory Protection Keys

[Dave Hansen]

Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---

 b/man7/pkey.7 |  241 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 241 insertions(+)

diff -puN /dev/null man7/pkey.7
--- /dev/null	2016-08-25 11:43:25.028408991 -0700
+++ b/man7/pkey.7	2016-09-13 12:42:56.171959285 -0700
@@ -0,0 +1,241 @@
+.\" Copyright (C) 2016 Intel Corporation
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date.  The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein.  The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.TH PKEYS 7 2016-03-03 "Linux" "Linux Programmer's Manual"
+.SH NAME
+pkeys \- overview of Memory Protection Keys
+.SH DESCRIPTION
+Memory Protection Keys (pkeys) are an extension to existing
+page-based memory permissions.
+Normal page permissions using
+page tables require expensive system calls and TLB invalidations
+when changing permissions.
+Memory Protection Keys provide a mechanism for changing
+protections without requiring modification of the page tables on
+every permission change.
+
+To use pkeys, software must first "tag" a page in the pagetables
+with a pkey.
+After this tag is in place, an application only has
+to change the contents of a register in order to remove write
+access, or all access to a tagged page.
+
+pkeys work in conjunction with the existing PROT_READ / PROT_WRITE /
+PROT_EXEC permissions passed to system calls like
+.BR mprotect (2)
+and
+.BR mmap (2),
+but always act to further restrict these traditional permission
+mechanisms.
+
+To use this feature, the processor must support it, and Linux
+must contain support for the feature on a given processor.
+As of early 2016 only future Intel x86 processors are supported,
+and this hardware supports 16 protection keys in each process.
+However, pkey 0 is used as the default key, so a maximum of 15
+are available for actual application use.
+The default key is assigned to any memory region for which a
+pkey has not been explicitly assigned via
+.BR pkey_mprotect(2).
+
+
+Protection keys has the potential to add a layer of security and
+reliability to applications.
+But, it has not been primarily designed as
+a security feature.
+For instance, WRPKRU is a completely unprivileged
+instruction, so pkeys are useless in any case that an attacker controls
+the PKRU register or can execute arbitrary instructions.
+
+Applications should be very careful to ensure that they do not "leak"
+protection keys.
+For instance, before an application calls
+.BR pkey_free(2)
+the application should be sure that no memory has that pkey assigned.
+If the application left the freed pkey assigned, a future user of
+that pkey might inadvertently change the permissions of an unrelated
+data structure which could impact security or stability.
+The kernel currently allows in-use pkeys to have
+.BR pkey_free(2)
+called on them because it would have processor or memory performance
+implications to perform the additional checks needed to disallow it.
+Implementation of these checks is left up to applications.
+Applications may implement these checks by searching the /proc
+filesystem smaps file for memory regions with the pkey assigned.
+More details can be found in
+.BR proc(5)
+
+Any application wanting to use protection keys needs to be able
+to function without them.
+They might be unavailable because the hardware that the
+application runs on does not support them, the kernel code does
+not contain support, the kernel support has been disabled, or
+because the keys have all been allocated, perhaps by a library
+the application is using.
+It is recommended that applications wanting to use protection
+keys should simply call
+.BR pkey_alloc(2)
+instead of attempting to detect support for the
+feature in any othee way.
+
+Although unnecessary, hardware support for protection keys may be
+enumerated with the cpuid instruction.
+Details on how to do this can be found in the Intel Software
+Developers Manual.
+The kernel performs this enumeration and exposes the information
+in /proc/cpuinfo under the "flags" field.
+"pku" in this field indicates hardware support for protection
+keys and "ospke" indicates that the kernel contains and has
+enabled protection keys support.
+
+Applications using threads and protection keys should be especially
+careful.
+Threads inherit the protection key rights of the parent at the time
+of the
+.BR clone (2),
+system call.
+Applications should either ensure that their own permissions are
+appropriate for child threads at the time of
+.BR clone (2)
+being called, or ensure that each child thread can perform its
+own initialization of protection key rights.
+.SS Protection Keys system calls
+The Linux kernel implements the following pkey-related system calls:
+.BR pkey_mprotect (2),
+.BR pkey_alloc (2),
+and
+.BR pkey_free (2) .
+.SH NOTES
+The Linux pkey system calls are available only if the kernel was
+fonfigured and built with the
+.BR CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
+option.
+.SH EXAMPLE
+.PP
+The program below allocates a page of memory with read/write
+permissions via PROT_READ|PROT_WRITE.
+It then writes some data to the memory and successfully reads it
+back.
+After that, it attempts to allocate a protection key and
+disallows access by using the WRPKRU instruction.
+It then tried to access
+.BR buffer
+which we now expect to cause a fatal signal to the application.
+.in +4n
+.nf
+.RB "$" " ./a.out"
+buffer contains: 73
+about to read buffer again...
+Segmentation fault (core dumped)
+.fi
+.in
+.SS Program source
+\&
+.nf
+#define _GNU_SOURCE
+#include <unistd.h>
+#include <sys/syscall.h>
+#include <stdio.h>
+#include <sys/mman.h>
+
+static inline void wrpkru(unsigned int pkru)
+{
+        unsigned int eax = pkru;
+        unsigned int ecx = 0;
+        unsigned int edx = 0;
+
+        asm volatile(".byte 0x0f,0x01,0xef\n\t"
+                     : : "a" (eax), "c" (ecx), "d" (edx));
+}
+
+int pkey_set(int pkey, unsigned long rights, unsigned long flags)
+{
+    unsigned int pkru = (rights << (2*pkey));
+    return wrpkru(pkru);
+}
+
+int pkey_mprotect(void *ptr, size_t size, unsigned long orig_prot, unsigned long pkey)
+{
+    return syscall(SYS_pkey_mprotect, ptr, size, orig_prot, pkey);
+}
+
+int pkey_alloc(void)
+{
+    return syscall(SYS_pkey_alloc, 0, 0);
+}
+
+int pkey_free(unsigned long pkey)
+{
+    return syscall(SYS_pkey_free, pkey);
+}
+
+int main(void)
+{
+    int status;
+    int pkey;
+    int *buffer;
+
+    /* Allocate one page of memory: */
+    buffer = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
+    if (buffer == MAP_FAILED)
+	    return -ENOMEM;
+
+    /* Put some random data in to the page (still OK to touch): */
+    (*buffer) = __LINE__;
+    printf("buffer contains: %d\\n", *buffer);
+
+    /* Allocate a protection key: */
+    pkey = pkey_alloc();
+    if (pkey < 0)
+	    return pkey;
+
+    /* Disable access to any memory with "pkey" set,
+     * even though there is none right now. */
+    status = pkey_set(pkey, PKEY_DISABLE_ACCESS, 0);
+    if (status)
+	    return status;
+
+    /*
+     * set the protection key on "buffer":
+     * Note that it is still read/write as far as mprotect() is,
+     * concerned and the previous pkey_set() overrides it.
+     */
+    status = pkey_mprotect(buffer, getpagesize(), PROT_READ|PROT_WRITE, pkey);
+    if (status)
+	    return status;
+
+    printf("about to read buffer again...\\n");
+    /* this will crash, because we have disallowed access: */
+    printf("buffer contains: %d\\n", *buffer);
+
+    status = pkey_free(pkey);
+    if (status)
+	    return status;
+
+    return 0;
+}
+.SH SEE ALSO
+.BR pkey_alloc (2),
+.BR pkey_free (2),
+.BR pkey_mprotect (2),
_

[PATCH 2/5] mprotect.2: add pkey_mprotect() syscall

[Dave Hansen]

Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---

 b/man2/mprotect.2 |   44 +++++++++++++++++++++++++++++++++++++++++---
 1 file changed, 41 insertions(+), 3 deletions(-)

diff -puN man2/mprotect.2~mprotect man2/mprotect.2
--- a/man2/mprotect.2~mprotect	2016-09-13 12:42:56.403959283 -0700
+++ b/man2/mprotect.2	2016-09-13 12:42:56.407959283 -0700
@@ -38,16 +38,19 @@
 .\"
 .TH MPROTECT 2 2015-07-23 "Linux" "Linux Programmer's Manual"
 .SH NAME
-mprotect \- set protection on a region of memory
+mprotect, pkey_mprotect \- set protection on a region of memory
 .SH SYNOPSIS
 .nf
 .B #include <sys/mman.h>
 .sp
 .BI "int mprotect(void *" addr ", size_t " len ", int " prot );
+.BI "int pkey_mprotect(void *" addr ", size_t " len ", int " prot ", int " pkey ");
 .fi
 .SH DESCRIPTION
 .BR mprotect ()
-changes protection for the calling process's memory page(s)
+and
+.BR pkey_mprotect ()
+change protection for the calling process's memory page(s)
 containing any part of the address range in the
 interval [\fIaddr\fP,\ \fIaddr\fP+\fIlen\fP\-1].
 .I addr
@@ -74,10 +77,19 @@ The memory can be modified.
 .TP
 .B PROT_EXEC
 The memory can be executed.
+.PP
+.I pkey
+is the protection key to assign to the memory.
+A pkey must be allocated with
+.BR pkey_alloc (2)
+before it is passed to
+.BR pkey_mprotect ().
 .SH RETURN VALUE
 On success,
 .BR mprotect ()
-returns zero.
+and
+.BR pkey_mprotect ()
+return zero.
 On error, \-1 is returned, and
 .I errno
 is set appropriately.
@@ -95,6 +107,8 @@ to mark it
 .B EINVAL
 \fIaddr\fP is not a valid pointer,
 or not a multiple of the system page size.
+Or: \fIpkey\fP has not been allocated with
+.BR pkey_alloc (2)
 .\" Or: both PROT_GROWSUP and PROT_GROWSDOWN were specified in 'prot'.
 .TP
 .B ENOMEM
@@ -165,6 +179,29 @@ but at a minimum can allow write access
 has been set, and must not allow any access if
 .B PROT_NONE
 has been set.
+
+Applications should be careful when mixing use of
+.BR mprotect ()
+and
+.BR pkey_mprotect () .
+On x86, when
+.BR mprotect ()
+is used with
+.IR prot
+set to
+.B PROT_EXEC
+a pkey is may be allocated and set on the memory implicitly
+by the kernel, but only when the pkey was 0 previously.
+
+On systems that do not support protection keys in hardware,
+.BR pkey_mprotect ()
+may still be used, but
+.IR pkey
+must be set to 0.
+When called this way, the operation of
+.BR pkey_mprotect ()
+is equivalent to
+.BR mprotect ().
 .SH EXAMPLE
 .\" sigaction.2 refers to this example
 .PP
@@ -246,3 +283,4 @@ main(int argc, char *argv[])
 .SH SEE ALSO
 .BR mmap (2),
 .BR sysconf (3)
+.BR pkey (7)
_
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/5] pkey_alloc.2: New page describing protection key allocation and free

[Dave Hansen]

Changes from last version:
 * Added text explaining that the kernel does not preserve PKRU
   contents controlling access to unallocated keys.

Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---

 b/man2/pkey_alloc.2 |  124 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 124 insertions(+)

diff -puN /dev/null man2/pkey_alloc.2
--- /dev/null	2016-08-25 11:43:25.028408991 -0700
+++ b/man2/pkey_alloc.2	2016-09-13 12:42:56.647959280 -0700
@@ -0,0 +1,124 @@
+.\" Copyright (C) 2016 Intel Corporation
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date.  The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein.  The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and author of this work.
+.\" %%%LICENSE_END
+.\"
+.TH PKEY_ALLOC 2 2016-03-03 "Linux" "Linux Programmer's Manual"
+.SH NAME
+pkey_alloc, pkey_free \- allocate or free a protection key
+.SH SYNOPSIS
+.nf
+.B #include <sys/mman.h>
+.sp
+.BI "int pkey_alloc(unsigned long " flags ", unsigned long " access_rights ");"
+.BI "int pkey_free(int " pkey ");"
+.fi
+.SH DESCRIPTION
+.BR pkey_alloc ()
+allocates a protection key and allows it to be passed to
+.BR pkey_mprotect (2) .
+.BR pkey_alloc ()
+is always safe to call whether or not the operating system
+supports protection keys.
+It can be used in lieu of any other enumeration of the feature
+and will simply return ENOSPC in the case that the operating
+system has no protection keys support.
+The kernel guarantees that the contents of the hardware rights
+register (PKRU) will be preserved only for allocated protection
+keys.
+Any time a key is unallocated (either before the first call
+returning that key from
+.BR pkey_alloc ()
+or after it is freed via
+.BR pkey_free ()
+), the kernel may make arbitrary changes to the parts of the
+rights register affecting access to that key.
+.PP
+.BR pkey_free ()
+frees a protection key and makes it available for later
+allocations.
+After a protection key has been freed, it may no longer be used
+in any protection-key-related operations.
+An application should not call
+.BR pkey_free ()
+on any protection key which has been assigned to an address
+range by
+.BR pkey_mprotect (2)
+and which is still in use.  The behavior in this case is
+undefined and may result in an error.
+.PP
+.RB ( pkey_alloc ())
+.I flags
+may contain zero or more disable operations:
+.TP
+.B PKEY_DISABLE_ACCESS
+Disable all data access to memory covered by the returned protection key.
+.TP
+.B PKEY_DISABLE_WRITE
+Disable write access to memory covered by the returned protection key.
+.SH RETURN VALUE
+On success,
+.BR pkey_alloc ()
+returns a positive protection key value.
+.BR pkey_free ()
+returns zero.
+On error, \-1 is returned, and
+.I errno
+is set appropriately.
+.SH ERRORS
+.TP
+.B EINVAL
+.IR pkey ,
+.IR flags ,
+or
+.I access_rights
+is invalid.
+.TP
+.B ENOSPC
+.(RB pkey_alloc ())
+All protection keys available for the current process have
+been allocated.
+The number of keys available is architecture-specific and
+implementation-specfic and may be reduced by kernel-internal use
+of certain keys.
+There are currently 15 keys available to user programs on x86.
+This will also be returned if the processor or operating system
+does not support protection keys.
+Applications should always be prepared to handle this error since
+factors outside of the application's control can reduce the number
+of available pkeys.
+.SH VERSIONS
+.BR pkey_alloc ()
+and
+.BR pkey_free ()
+were added to Linux in kernel <FIXME>;
+library support was added to glibc in version <FIXME>.
+.SH CONFORMING TO
+The
+.BR pkey_alloc ()
+and
+.BR pkey_free ()
+system calls are Linux-specific.
+.SH
+.SH SEE ALSO
+.BR pkey_mprotect (2),
+.BR pkey (7)
_

[PATCH 4/5] sigaction.2: describe siginfo changes from pkey-induced signals

[Dave Hansen]

Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---

 b/man2/sigaction.2 |    9 +++++++++
 1 file changed, 9 insertions(+)

diff -puN man2/sigaction.2~sigaction man2/sigaction.2
--- a/man2/sigaction.2~sigaction	2016-09-13 12:42:56.883959277 -0700
+++ b/man2/sigaction.2	2016-09-13 12:42:56.883959277 -0700
@@ -311,6 +311,8 @@ siginfo_t {
                               (since Linux 3.5) */
     unsigned int si_arch;  /* Architecture of attempted system call
                               (since Linux 3.5) */
+    unsigned int si_pkey;  /* Protection key set on si_addr
+                              (since Linux <FIXME>) */
 }
 .fi
 .in
@@ -597,6 +599,13 @@ Coprocessor error.
 .TP
 .B ILL_BADSTK
 Internal stack error.
+.TP
+.B SEGV_PKUERR
+Access was denied by memory protection keys.
+See:
+.BR pkeys (7).
+The protection key which applied to this access is available via
+.I si_pkey
 .RE
 .PP
 The following values can be placed in
_
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/5] proc.5: describe new ProtectionKey smaps field

[Dave Hansen]

Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---

 b/man5/proc.5 |    7 +++++++
 1 file changed, 7 insertions(+)

diff -puN man5/proc.5~proc man5/proc.5
--- a/man5/proc.5~proc	2016-09-13 12:42:57.123959275 -0700
+++ b/man5/proc.5	2016-09-13 12:42:57.127959275 -0700
@@ -1633,6 +1633,13 @@ The codes are the following:
     nh  - no-huge page advise flag
     mg  - mergeable advise flag
 
+"ProtectionKey" field contains the memory protection key (see
+.BR pkeys (5))
+associated with the virtual memory area.
+Only present if the kernel was built with the
+.B CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
+configuration option. (since Linux 4.6)
+
 The
 .IR /proc/[pid]/smaps
 file is present only if the
_
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] pkey.7: New page with overview of Memory Protection Keys

[Michael Kerrisk (man-pages)]

Hello Dave,

On 13 September 2016 at 21:44, Dave Hansen <dave.hansen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>
> Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>

Now that these system calls have hit mainline, are there any updates
to the 13 Sep series of man page patches?

Cheers,

Michael

> ---
>
>  b/man7/pkey.7 |  241 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 241 insertions(+)
>
> diff -puN /dev/null man7/pkey.7
> --- /dev/null   2016-08-25 11:43:25.028408991 -0700
> +++ b/man7/pkey.7       2016-09-13 12:42:56.171959285 -0700
> @@ -0,0 +1,241 @@
> +.\" Copyright (C) 2016 Intel Corporation
> +.\"
> +.\" %%%LICENSE_START(VERBATIM)
> +.\" Permission is granted to make and distribute verbatim copies of this
> +.\" manual provided the copyright notice and this permission notice are
> +.\" preserved on all copies.
> +.\"
> +.\" Permission is granted to copy and distribute modified versions of this
> +.\" manual under the conditions for verbatim copying, provided that the
> +.\" entire resulting derived work is distributed under the terms of a
> +.\" permission notice identical to this one.
> +.\"
> +.\" Since the Linux kernel and libraries are constantly changing, this
> +.\" manual page may be incorrect or out-of-date.  The author(s) assume no
> +.\" responsibility for errors or omissions, or for damages resulting from
> +.\" the use of the information contained herein.  The author(s) may not
> +.\" have taken the same level of care in the production of this manual,
> +.\" which is licensed free of charge, as they might when working
> +.\" professionally.
> +.\"
> +.\" Formatted or processed versions of this manual, if unaccompanied by
> +.\" the source, must acknowledge the copyright and authors of this work.
> +.\" %%%LICENSE_END
> +.\"
> +.TH PKEYS 7 2016-03-03 "Linux" "Linux Programmer's Manual"
> +.SH NAME
> +pkeys \- overview of Memory Protection Keys
> +.SH DESCRIPTION
> +Memory Protection Keys (pkeys) are an extension to existing
> +page-based memory permissions.
> +Normal page permissions using
> +page tables require expensive system calls and TLB invalidations
> +when changing permissions.
> +Memory Protection Keys provide a mechanism for changing
> +protections without requiring modification of the page tables on
> +every permission change.
> +
> +To use pkeys, software must first "tag" a page in the pagetables
> +with a pkey.
> +After this tag is in place, an application only has
> +to change the contents of a register in order to remove write
> +access, or all access to a tagged page.
> +
> +pkeys work in conjunction with the existing PROT_READ / PROT_WRITE /
> +PROT_EXEC permissions passed to system calls like
> +.BR mprotect (2)
> +and
> +.BR mmap (2),
> +but always act to further restrict these traditional permission
> +mechanisms.
> +
> +To use this feature, the processor must support it, and Linux
> +must contain support for the feature on a given processor.
> +As of early 2016 only future Intel x86 processors are supported,
> +and this hardware supports 16 protection keys in each process.
> +However, pkey 0 is used as the default key, so a maximum of 15
> +are available for actual application use.
> +The default key is assigned to any memory region for which a
> +pkey has not been explicitly assigned via
> +.BR pkey_mprotect(2).
> +
> +
> +Protection keys has the potential to add a layer of security and
> +reliability to applications.
> +But, it has not been primarily designed as
> +a security feature.
> +For instance, WRPKRU is a completely unprivileged
> +instruction, so pkeys are useless in any case that an attacker controls
> +the PKRU register or can execute arbitrary instructions.
> +
> +Applications should be very careful to ensure that they do not "leak"
> +protection keys.
> +For instance, before an application calls
> +.BR pkey_free(2)
> +the application should be sure that no memory has that pkey assigned.
> +If the application left the freed pkey assigned, a future user of
> +that pkey might inadvertently change the permissions of an unrelated
> +data structure which could impact security or stability.
> +The kernel currently allows in-use pkeys to have
> +.BR pkey_free(2)
> +called on them because it would have processor or memory performance
> +implications to perform the additional checks needed to disallow it.
> +Implementation of these checks is left up to applications.
> +Applications may implement these checks by searching the /proc
> +filesystem smaps file for memory regions with the pkey assigned.
> +More details can be found in
> +.BR proc(5)
> +
> +Any application wanting to use protection keys needs to be able
> +to function without them.
> +They might be unavailable because the hardware that the
> +application runs on does not support them, the kernel code does
> +not contain support, the kernel support has been disabled, or
> +because the keys have all been allocated, perhaps by a library
> +the application is using.
> +It is recommended that applications wanting to use protection
> +keys should simply call
> +.BR pkey_alloc(2)
> +instead of attempting to detect support for the
> +feature in any othee way.
> +
> +Although unnecessary, hardware support for protection keys may be
> +enumerated with the cpuid instruction.
> +Details on how to do this can be found in the Intel Software
> +Developers Manual.
> +The kernel performs this enumeration and exposes the information
> +in /proc/cpuinfo under the "flags" field.
> +"pku" in this field indicates hardware support for protection
> +keys and "ospke" indicates that the kernel contains and has
> +enabled protection keys support.
> +
> +Applications using threads and protection keys should be especially
> +careful.
> +Threads inherit the protection key rights of the parent at the time
> +of the
> +.BR clone (2),
> +system call.
> +Applications should either ensure that their own permissions are
> +appropriate for child threads at the time of
> +.BR clone (2)
> +being called, or ensure that each child thread can perform its
> +own initialization of protection key rights.
> +.SS Protection Keys system calls
> +The Linux kernel implements the following pkey-related system calls:
> +.BR pkey_mprotect (2),
> +.BR pkey_alloc (2),
> +and
> +.BR pkey_free (2) .
> +.SH NOTES
> +The Linux pkey system calls are available only if the kernel was
> +fonfigured and built with the
> +.BR CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
> +option.
> +.SH EXAMPLE
> +.PP
> +The program below allocates a page of memory with read/write
> +permissions via PROT_READ|PROT_WRITE.
> +It then writes some data to the memory and successfully reads it
> +back.
> +After that, it attempts to allocate a protection key and
> +disallows access by using the WRPKRU instruction.
> +It then tried to access
> +.BR buffer
> +which we now expect to cause a fatal signal to the application.
> +.in +4n
> +.nf
> +.RB "$" " ./a.out"
> +buffer contains: 73
> +about to read buffer again...
> +Segmentation fault (core dumped)
> +.fi
> +.in
> +.SS Program source
> +\&
> +.nf
> +#define _GNU_SOURCE
> +#include <unistd.h>
> +#include <sys/syscall.h>
> +#include <stdio.h>
> +#include <sys/mman.h>
> +
> +static inline void wrpkru(unsigned int pkru)
> +{
> +        unsigned int eax = pkru;
> +        unsigned int ecx = 0;
> +        unsigned int edx = 0;
> +
> +        asm volatile(".byte 0x0f,0x01,0xef\n\t"
> +                     : : "a" (eax), "c" (ecx), "d" (edx));
> +}
> +
> +int pkey_set(int pkey, unsigned long rights, unsigned long flags)
> +{
> +    unsigned int pkru = (rights << (2*pkey));
> +    return wrpkru(pkru);
> +}
> +
> +int pkey_mprotect(void *ptr, size_t size, unsigned long orig_prot, unsigned long pkey)
> +{
> +    return syscall(SYS_pkey_mprotect, ptr, size, orig_prot, pkey);
> +}
> +
> +int pkey_alloc(void)
> +{
> +    return syscall(SYS_pkey_alloc, 0, 0);
> +}
> +
> +int pkey_free(unsigned long pkey)
> +{
> +    return syscall(SYS_pkey_free, pkey);
> +}
> +
> +int main(void)
> +{
> +    int status;
> +    int pkey;
> +    int *buffer;
> +
> +    /* Allocate one page of memory: */
> +    buffer = mmap(NULL, getpagesize(), PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0);
> +    if (buffer == MAP_FAILED)
> +           return -ENOMEM;
> +
> +    /* Put some random data in to the page (still OK to touch): */
> +    (*buffer) = __LINE__;
> +    printf("buffer contains: %d\\n", *buffer);
> +
> +    /* Allocate a protection key: */
> +    pkey = pkey_alloc();
> +    if (pkey < 0)
> +           return pkey;
> +
> +    /* Disable access to any memory with "pkey" set,
> +     * even though there is none right now. */
> +    status = pkey_set(pkey, PKEY_DISABLE_ACCESS, 0);
> +    if (status)
> +           return status;
> +
> +    /*
> +     * set the protection key on "buffer":
> +     * Note that it is still read/write as far as mprotect() is,
> +     * concerned and the previous pkey_set() overrides it.
> +     */
> +    status = pkey_mprotect(buffer, getpagesize(), PROT_READ|PROT_WRITE, pkey);
> +    if (status)
> +           return status;
> +
> +    printf("about to read buffer again...\\n");
> +    /* this will crash, because we have disallowed access: */
> +    printf("buffer contains: %d\\n", *buffer);
> +
> +    status = pkey_free(pkey);
> +    if (status)
> +           return status;
> +
> +    return 0;
> +}
> +.SH SEE ALSO
> +.BR pkey_alloc (2),
> +.BR pkey_free (2),
> +.BR pkey_mprotect (2),
> _



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] pkey.7: New page with overview of Memory Protection Keys

[Dave Hansen]

On 10/11/2016 11:25 PM, Michael Kerrisk (man-pages) wrote:
> On 13 September 2016 at 21:44, Dave Hansen <dave.hansen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>> Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> 
> Now that these system calls have hit mainline, are there any updates
> to the 13 Sep series of man page patches?

The 13 Sep version is the latest version of the man pages.  Those fully
describe the functionality that hit mainline and I haven't updated them
since 13 Sep.
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] pkey.7: New page with overview of Memory Protection Keys

[Michael Kerrisk (man-pages)]

Hi Dave,

On 10/12/2016 06:41 PM, Dave Hansen wrote:
> On 10/11/2016 11:25 PM, Michael Kerrisk (man-pages) wrote:
>> On 13 September 2016 at 21:44, Dave Hansen <dave.hansen-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org> wrote:
>>> Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
>>
>> Now that these system calls have hit mainline, are there any updates
>> to the 13 Sep series of man page patches?
> 
> The 13 Sep version is the latest version of the man pages.  Those fully
> describe the functionality that hit mainline and I haven't updated them
> since 13 Sep.

Okay -- I've merged these pages. I did a fair bit of editing, mainly
wording fixes, and textual reorganization, but also adding a few
details that were missing. Could you take a look at the pkey_alloc(2),
mprotect(2), and pkeys(7) page that are currently in man-pages
Git and let me know if anything needs fixing, or if there are any
details  that it occurs to you still need to be added.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] pkey.7: New page with overview of Memory Protection Keys

[Dave Hansen]

On 10/17/2016 05:04 AM, Michael Kerrisk (man-pages) wrote:
>> The 13 Sep version is the latest version of the man pages.  Those fully
>> describe the functionality that hit mainline and I haven't updated them
>> since 13 Sep.
> 
> Okay -- I've merged these pages. I did a fair bit of editing, mainly
> wording fixes, and textual reorganization, but also adding a few
> details that were missing. Could you take a look at the pkey_alloc(2),
> mprotect(2), and pkeys(7) page that are currently in man-pages
> Git and let me know if anything needs fixing, or if there are any
> details  that it occurs to you still need to be added.

These look good, except for a bit of signal handing description that I
neglected to send.  I'll have a patch out for it momentarily.

--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] pkey.7: New page with overview of Memory Protection Keys

[Michael Kerrisk (man-pages)]

On 10/18/2016 12:06 AM, Dave Hansen wrote:
> On 10/17/2016 05:04 AM, Michael Kerrisk (man-pages) wrote:
>>> The 13 Sep version is the latest version of the man pages.  Those fully
>>> describe the functionality that hit mainline and I haven't updated them
>>> since 13 Sep.
>>
>> Okay -- I've merged these pages. I did a fair bit of editing, mainly
>> wording fixes, and textual reorganization, but also adding a few
>> details that were missing. Could you take a look at the pkey_alloc(2),
>> mprotect(2), and pkeys(7) page that are currently in man-pages
>> Git and let me know if anything needs fixing, or if there are any
>> details  that it occurs to you still need to be added.
> 
> These look good, except for a bit of signal handing description that I
> neglected to send.  I'll have a patch out for it momentarily.
> 

Thanks for checking the pages!

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/