All of lore.kernel.org
 help / color / mirror / Atom feed
From: tip-bot for Dave Hansen <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: linux-kernel@vger.kernel.org, dave@sr71.net, tglx@linutronix.de,
	dave.hansen@linux.intel.com, hpa@zytor.com, mingo@kernel.org
Subject: [tip:mm/pkeys] x86/pkeys: Default to a restrictive init PKRU
Date: Fri, 9 Sep 2016 04:13:42 -0700	[thread overview]
Message-ID: <tip-acd547b29880800d29222c4632d2c145e401988c@git.kernel.org> (raw)
In-Reply-To: <20160729163021.F3C25D4A@viggo.jf.intel.com>

Commit-ID:  acd547b29880800d29222c4632d2c145e401988c
Gitweb:     http://git.kernel.org/tip/acd547b29880800d29222c4632d2c145e401988c
Author:     Dave Hansen <dave.hansen@linux.intel.com>
AuthorDate: Fri, 29 Jul 2016 09:30:21 -0700
Committer:  Thomas Gleixner <tglx@linutronix.de>
CommitDate: Fri, 9 Sep 2016 13:02:28 +0200

x86/pkeys: Default to a restrictive init PKRU

PKRU is the register that lets you disallow writes or all access to a given
protection key.

The XSAVE hardware defines an "init state" of 0 for PKRU: its most
permissive state, allowing access/writes to everything.  Since we start off
all new processes with the init state, we start all processes off with the
most permissive possible PKRU.

This is unfortunate.  If a thread is clone()'d [1] before a program has
time to set PKRU to a restrictive value, that thread will be able to write
to all data, no matter what pkey is set on it.  This weakens any integrity
guarantees that we want pkeys to provide.

To fix this, we define a very restrictive PKRU to override the
XSAVE-provided value when we create a new FPU context.  We choose a value
that only allows access to pkey 0, which is as restrictive as we can
practically make it.

This does not cause any practical problems with applications using
protection keys because we require them to specify initial permissions for
each key when it is allocated, which override the restrictive default.

In the end, this ensures that threads which do not know how to manage their
own pkey rights can not do damage to data which is pkey-protected.

I would have thought this was a pretty contrived scenario, except that I
heard a bug report from an MPX user who was creating threads in some very
early code before main().  It may be crazy, but folks evidently _do_ it.

Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-arch@vger.kernel.org
Cc: Dave Hansen <dave@sr71.net>
Cc: mgorman@techsingularity.net
Cc: arnd@arndb.de
Cc: linux-api@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: luto@kernel.org
Cc: akpm@linux-foundation.org
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/20160729163021.F3C25D4A@viggo.jf.intel.com
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

---
 Documentation/kernel-parameters.txt |  5 +++++
 arch/x86/include/asm/pkeys.h        |  1 +
 arch/x86/kernel/fpu/core.c          |  4 ++++
 arch/x86/mm/pkeys.c                 | 38 +++++++++++++++++++++++++++++++++++++
 include/linux/pkeys.h               |  4 ++++
 5 files changed, 52 insertions(+)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index a4f4d69..3725976 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1643,6 +1643,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
 	initrd=		[BOOT] Specify the location of the initial ramdisk
 
+	init_pkru=	[x86] Specify the default memory protection keys rights
+			register contents for all processes.  0x55555554 by
+			default (disallow access to all but pkey 0).  Can
+			override in debugfs after boot.
+
 	inport.irq=	[HW] Inport (ATI XL and Microsoft) busmouse driver
 			Format: <irq>
 
diff --git a/arch/x86/include/asm/pkeys.h b/arch/x86/include/asm/pkeys.h
index b406889..34684ad 100644
--- a/arch/x86/include/asm/pkeys.h
+++ b/arch/x86/include/asm/pkeys.h
@@ -100,5 +100,6 @@ extern int arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
 		unsigned long init_val);
 extern int __arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
 		unsigned long init_val);
+extern void copy_init_pkru_to_fpregs(void);
 
 #endif /*_ASM_X86_PKEYS_H */
diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c
index 3fc03a0..4700401 100644
--- a/arch/x86/kernel/fpu/core.c
+++ b/arch/x86/kernel/fpu/core.c
@@ -12,6 +12,7 @@
 #include <asm/traps.h>
 
 #include <linux/hardirq.h>
+#include <linux/pkeys.h>
 
 #define CREATE_TRACE_POINTS
 #include <asm/trace/fpu.h>
@@ -505,6 +506,9 @@ static inline void copy_init_fpstate_to_fpregs(void)
 		copy_kernel_to_fxregs(&init_fpstate.fxsave);
 	else
 		copy_kernel_to_fregs(&init_fpstate.fsave);
+
+	if (boot_cpu_has(X86_FEATURE_OSPKE))
+		copy_init_pkru_to_fpregs();
 }
 
 /*
diff --git a/arch/x86/mm/pkeys.c b/arch/x86/mm/pkeys.c
index e6113bb..ddc5494 100644
--- a/arch/x86/mm/pkeys.c
+++ b/arch/x86/mm/pkeys.c
@@ -121,3 +121,41 @@ int __arch_override_mprotect_pkey(struct vm_area_struct *vma, int prot, int pkey
 	 */
 	return vma_pkey(vma);
 }
+
+#define PKRU_AD_KEY(pkey)	(PKRU_AD_BIT << ((pkey) * PKRU_BITS_PER_PKEY))
+
+/*
+ * Make the default PKRU value (at execve() time) as restrictive
+ * as possible.  This ensures that any threads clone()'d early
+ * in the process's lifetime will not accidentally get access
+ * to data which is pkey-protected later on.
+ */
+u32 init_pkru_value = PKRU_AD_KEY( 1) | PKRU_AD_KEY( 2) | PKRU_AD_KEY( 3) |
+		      PKRU_AD_KEY( 4) | PKRU_AD_KEY( 5) | PKRU_AD_KEY( 6) |
+		      PKRU_AD_KEY( 7) | PKRU_AD_KEY( 8) | PKRU_AD_KEY( 9) |
+		      PKRU_AD_KEY(10) | PKRU_AD_KEY(11) | PKRU_AD_KEY(12) |
+		      PKRU_AD_KEY(13) | PKRU_AD_KEY(14) | PKRU_AD_KEY(15);
+
+/*
+ * Called from the FPU code when creating a fresh set of FPU
+ * registers.  This is called from a very specific context where
+ * we know the FPU regstiers are safe for use and we can use PKRU
+ * directly.  The fact that PKRU is only available when we are
+ * using eagerfpu mode makes this possible.
+ */
+void copy_init_pkru_to_fpregs(void)
+{
+	u32 init_pkru_value_snapshot = READ_ONCE(init_pkru_value);
+	/*
+	 * Any write to PKRU takes it out of the XSAVE 'init
+	 * state' which increases context switch cost.  Avoid
+	 * writing 0 when PKRU was already 0.
+	 */
+	if (!init_pkru_value_snapshot && !read_pkru())
+		return;
+	/*
+	 * Override the PKRU state that came from 'init_fpstate'
+	 * with the baseline from the process.
+	 */
+	write_pkru(init_pkru_value_snapshot);
+}
diff --git a/include/linux/pkeys.h b/include/linux/pkeys.h
index 8ff2112..e4c08c1 100644
--- a/include/linux/pkeys.h
+++ b/include/linux/pkeys.h
@@ -35,6 +35,10 @@ static inline int arch_set_user_pkey_access(struct task_struct *tsk, int pkey,
 	return 0;
 }
 
+static inline void copy_init_pkru_to_fpregs(void)
+{
+}
+
 #endif /* ! CONFIG_ARCH_HAS_PKEYS */
 
 #endif /* _LINUX_PKEYS_H */

  parent reply	other threads:[~2016-09-09 11:15 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-29 16:30 [PATCH 00/10] [v6] System Calls for Memory Protection Keys Dave Hansen
2016-07-29 16:30 ` Dave Hansen
2016-07-29 16:30 ` [PATCH 01/10] x86, pkeys: add fault handling for PF_PK page fault bit Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:10   ` [tip:mm/pkeys] x86/pkeys: Add " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 02/10] mm: implement new pkey_mprotect() system call Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:11   ` [tip:mm/pkeys] mm: Implement " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 03/10] x86, pkeys: make mprotect_key() mask off additional vm_flags Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:11   ` [tip:mm/pkeys] x86/pkeys: Make " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 04/10] x86, pkeys: allocation/free syscalls Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:12   ` [tip:mm/pkeys] x86/pkeys: Allocation/free syscalls tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 05/10] x86: wire up protection keys system calls Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:12   ` [tip:mm/pkeys] x86: Wire " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 06/10] generic syscalls: wire up memory protection keys syscalls Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:12   ` [tip:mm/pkeys] generic syscalls: Wire " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 07/10] pkeys: add details of system call use to Documentation/ Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:13   ` [tip:mm/pkeys] pkeys: Add " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 08/10] x86, pkeys: default to a restrictive init PKRU Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-07-29 17:29   ` Andy Lutomirski
2016-07-29 17:29     ` Andy Lutomirski
2016-07-29 17:50     ` Dave Hansen
2016-07-29 17:50       ` Dave Hansen
2016-07-29 19:44       ` Andy Lutomirski
2016-07-29 19:44         ` Andy Lutomirski
2016-08-01 14:42   ` Vlastimil Babka
2016-08-01 14:42     ` Vlastimil Babka
2016-08-01 14:58     ` Dave Hansen
2016-08-01 14:58       ` Dave Hansen
2016-08-02  8:20       ` Vlastimil Babka
2016-08-02  8:20         ` Vlastimil Babka
2016-09-09 11:13   ` tip-bot for Dave Hansen [this message]
2016-07-29 16:30 ` [PATCH 09/10] x86, pkeys: allow configuration of init_pkru Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-08-02  8:28   ` Vlastimil Babka
2016-08-02  8:28     ` Vlastimil Babka
2016-08-02 14:37     ` Dave Hansen
2016-08-02 14:37       ` Dave Hansen
2016-09-09 11:14   ` [tip:mm/pkeys] x86/pkeys: Allow " tip-bot for Dave Hansen
2016-07-29 16:30 ` [PATCH 10/10] x86, pkeys: add self-tests Dave Hansen
2016-07-29 16:30   ` Dave Hansen
2016-09-09 11:14   ` [tip:mm/pkeys] x86/pkeys: Add self-tests tip-bot for 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=tip-acd547b29880800d29222c4632d2c145e401988c@git.kernel.org \
    --to=tipbot@zytor.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=dave@sr71.net \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tip-commits@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=tglx@linutronix.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.