From: Dave Hansen <dave-gkUM19QKKo4@public.gmane.org>
To: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
Cc: linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
Dave Hansen <dave-gkUM19QKKo4@public.gmane.org>
Subject: [PATCH 1/6] pkey.7: New page with overview of Memory Protection Keys
Date: Wed, 08 Jun 2016 10:34:23 -0700 [thread overview]
Message-ID: <20160608173423.A35B7734@ray> (raw)
In-Reply-To: <20160608173351.5CF7B2D3@ray>
Signed-off-by: Dave Hansen <dave.hansen-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
---
b/man7/pkey.7 | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 230 insertions(+)
diff -puN /dev/null man7/pkey.7
--- /dev/null 2016-03-09 16:12:12.816871985 -0800
+++ b/man7/pkey.7 2016-06-08 10:32:43.040409618 -0700
@@ -0,0 +1,230 @@
+.\" 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 ()
+instead of attempting to detect support for the
+feature in any othee way.
+
+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.
+.SS Protection Keys system calls
+The Linux kernel implements the following pkey-related system calls:
+.BR pkey_mprotect (2),
+.BR pkey_alloc (2),
+.BR pkey_free (2),
+.BR pkey_set (2),
+and
+.BR pkey_get (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 to it by passsing
+.BR PKEY_DISABLE_ACCESS
+to
+.BR pkey_set (2).
+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>
+
+int pkey_get(int pkey, unsigned long flags)
+{
+ return syscall(SYS_pkey_get, pkey);
+}
+
+int pkey_set(int pkey, unsigned long rights, unsigned long flags)
+{
+ return syscall(SYS_pkey_set, pkey, rights, flags);
+}
+
+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_get (2),
+.BR pkey_mprotect (2),
+.BR pkey_set (2),
_
--
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
next prev parent reply other threads:[~2016-06-08 17:34 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-08 17:33 [PATCH 0/6] [RFCv4] add manpages for Memory Protection Keys Dave Hansen
2016-06-08 17:34 ` Dave Hansen [this message]
2016-10-12 8:41 ` [PATCH 1/6] pkey.7: New page with overview of " Florian Weimer
[not found] ` <ece20e5b-981d-e5c4-7b71-b1bd538c6937-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-10-12 16:03 ` Dave Hansen
2016-06-08 17:34 ` [PATCH 2/6] mprotect.2: add pkey_mprotect() syscall Dave Hansen
2016-06-08 17:35 ` [PATCH 3/6] pkey_alloc.2: New page describing protection key allocation and free Dave Hansen
2016-06-08 17:35 ` [PATCH 4/6] pkey_get.2: New page desribing pkey rights manipulation syscalls Dave Hansen
2016-06-08 17:36 ` [PATCH 5/6] sigaction.2: describe siginfo changes from pkey-induced signals Dave Hansen
2016-06-08 17:36 ` [PATCH 6/6] proc.5: describe new ProtectionKey smaps field Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160608173423.A35B7734@ray \
--to=dave-gkum19qkko4@public.gmane.org \
--cc=linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=x86-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).