[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 29 Jan 2018 17:02:39 -0800
From: Dan Williams <dan.j.williams@...el.com>
To: tglx@...utronix.de, mingo@...nel.org
Cc: linux-arch@...r.kernel.org, Tom Lendacky <thomas.lendacky@....com>,
Andi Kleen <ak@...ux.intel.com>, Kees Cook <keescook@...omium.org>,
kernel-hardening@...ts.openwall.com, gregkh@...uxfoundation.org,
x86@...nel.org, linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
Al Viro <viro@...iv.linux.org.uk>, "H. Peter Anvin" <hpa@...or.com>,
torvalds@...ux-foundation.org, alan@...ux.intel.com
Subject: [PATCH v6 05/13] x86: introduce __uaccess_begin_nospec
For __get_user() paths, do not allow the kernel to speculate on the
value of a user controlled pointer. In addition to the 'stac'
instruction for Supervisor Mode Access Protection (SMAP), a
barrier_nospec() causes the access_ok() result to resolve in the
pipeline before the CPU might take any speculative action on the pointer
value. Given the cost of 'stac' the speculation barrier is placed after
'stac' to hopefully overlap the cost of disabling SMAP with the cost of
flushing the instruction pipeline.
Since __get_user is a major kernel interface that deals with user
controlled pointers, the __uaccess_begin_nospec() mechanism will prevent
speculative execution past an access_ok() permission check. While
speculative execution past access_ok() is not enough to lead to a kernel
memory leak, it is a necessary precondition.
To be clear, __uaccess_begin_nospec() is addressing a class of potential
problems near __get_user() usages.
Note, that while the barrier_nospec() in __uaccess_begin_nospec() is
used to protect __get_user(), pointer masking similar to
array_index_nospec() will be used for get_user() since it incorporates a
bounds check near the usage.
There are no functional changes in this patch.
Suggested-by: Linus Torvalds <torvalds@...ux-foundation.org>
Suggested-by: Andi Kleen <ak@...ux.intel.com>
Suggested-by: Ingo Molnar <mingo@...hat.com>
Cc: Tom Lendacky <thomas.lendacky@....com>
Cc: Al Viro <viro@...iv.linux.org.uk>
Cc: Kees Cook <keescook@...omium.org>
Cc: Thomas Gleixner <tglx@...utronix.de>
Cc: "H. Peter Anvin" <hpa@...or.com>
Cc: x86@...nel.org
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
---
arch/x86/include/asm/uaccess.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
index 574dff4d2913..663e9bde9fc9 100644
--- a/arch/x86/include/asm/uaccess.h
+++ b/arch/x86/include/asm/uaccess.h
@@ -124,6 +124,11 @@ extern int __get_user_bad(void);
#define __uaccess_begin() stac()
#define __uaccess_end() clac()
+#define __uaccess_begin_nospec() \
+({ \
+ stac(); \
+ barrier_nospec(); \
+})
/*
* This is a type: either unsigned long, if the argument fits into
@@ -487,6 +492,10 @@ struct __large_struct { unsigned long buf[100]; };
__uaccess_begin(); \
barrier();
+#define uaccess_try_nospec do { \
+ current->thread.uaccess_err = 0; \
+ __uaccess_begin_nospec(); \
+
#define uaccess_catch(err) \
__uaccess_end(); \
(err) |= (current->thread.uaccess_err ? -EFAULT : 0); \
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
