From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751898AbbHMCXq (ORCPT ); Wed, 12 Aug 2015 22:23:46 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:37056 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751205AbbHMCXp (ORCPT ); Wed, 12 Aug 2015 22:23:45 -0400 X-Originating-IP: 50.43.43.179 Date: Wed, 12 Aug 2015 19:23:37 -0700 From: Josh Triplett To: Kees Cook Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86, vsyscall: add CONFIG to control default Message-ID: <20150813022336.GA26334@x> References: <20150813005519.GA11696@www.outflux.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150813005519.GA11696@www.outflux.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 12, 2015 at 05:55:19PM -0700, Kees Cook wrote: > Most modern systems can run with vsyscall=none. In an effort to provide > a way for build-time defaults to lack legacy settings, this adds a new > CONFIG to select the type of vsyscall mapping to use, similar to the > existing "vsyscall" command line parameter. > > Signed-off-by: Kees Cook Seems reasonable to me. One question, though: is there *any* reason to choose "native" over "emulate"? (Does "emulate" have a sufficient performance penalty to matter, and do people running old glibc really care about that performance while still not wanting to upgrade?) If there is a reason, could you please document it in the descriptions of the "native" and "emulate" options (as an upside and a downside, respectively)? If there isn't, you might consider a patch to remove "native". > arch/x86/Kconfig | 49 +++++++++++++++++++++++++++++++++++ > arch/x86/entry/vsyscall/vsyscall_64.c | 9 ++++++- > 2 files changed, 57 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index b3a1a5d77d92..fbd0fad714a1 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -2010,6 +2010,55 @@ config COMPAT_VDSO > If unsure, say N: if you are compiling your own kernel, you > are unlikely to be using a buggy version of glibc. > > +choice > + prompt "vsyscall table for legacy applications" > + depends on X86_64 > + default LEGACY_VSYSCALL_EMULATE > + help > + Legacy user code that does not know how to find the vDSO expects > + to be able to issue three syscalls by calling fixed addresses in > + kernel space. Since this location is not randomized with ASLR, > + it can be used to assist security vulnerability exploitation. > + > + This setting can be changed at boot time via the kernel command > + line parameter vsyscall=[native|emulate|none]. > + > + On a system with recent enough glibc (2.14 or newer) and no > + static binaries, you can say None without a performance penalty > + to improve security. > + > + If unsure, select "Emulate". > + > + config LEGACY_VSYSCALL_NATIVE > + bool "Native" > + help > + Actual executable code is located in the fixed vsyscall > + address mapping, implementing time() efficiently. Since > + this makes the mapping executable, it can be used during > + security vulnerability exploitation (traditionally as > + ROP gadgets). This configuration is not recommended. > + > + config LEGACY_VSYSCALL_EMULATE > + bool "Emulate" > + help > + The kernel traps and emulates calls into the fixed > + vsyscall address mapping. This makes the mapping > + non-executable, but it still contains known contents, > + which could be used in certain rare security vulnerability > + exploits. This configuration is recommended when userspace > + still uses the vsyscall area. > + > + config LEGACY_VSYSCALL_NONE > + bool "None" > + help > + There will be no vsyscall mapping at all. This will > + eliminate any risk of ASLR bypass due to the vsyscall > + fixed address mapping. Attempts to use the vsyscalls > + will be reported to dmesg, so that either old or > + malicious userspace programs can be identified. > + > +endchoice > + > config CMDLINE_BOOL > bool "Built-in kernel command line" > ---help--- > diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c > index 2dcc6ff6fdcc..47e2904b043b 100644 > --- a/arch/x86/entry/vsyscall/vsyscall_64.c > +++ b/arch/x86/entry/vsyscall/vsyscall_64.c > @@ -38,7 +38,14 @@ > #define CREATE_TRACE_POINTS > #include "vsyscall_trace.h" > > -static enum { EMULATE, NATIVE, NONE } vsyscall_mode = EMULATE; > +static enum { EMULATE, NATIVE, NONE } vsyscall_mode = > +#ifdef CONFIG_LEGACY_VSYSCALL_NATIVE > + NATIVE; > +#elif CONFIG_LEGACY_VSYSCALL_NONE > + NONE; > +#else > + EMULATE; > +#endif > > static int __init vsyscall_setup(char *str) > { > -- > 1.9.1 > > > -- > Kees Cook > Chrome OS Security