| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 6 Jun 2011 14:34:11 GMT
From: tip-bot for Ingo Molnar <mingo@...e.hu>
To: linux-tip-commits@...r.kernel.org
Cc: mingo@...hat.com, brgerst@...il.com, torvalds@...ux-foundation.org,
mikpe@...uu.se, richard.weinberger@...il.com, jj@...osbits.net,
JBeulich@...ell.com, tglx@...utronix.de, Louis.Rilling@...labs.com,
hpa@...or.com, linux-kernel@...r.kernel.org, luto@....edu,
andi@...stfloor.org, bp@...en8.de, arjan@...radead.org,
mingo@...e.hu
Subject: [tip:x86/vdso] x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS
Commit-ID: 1593843e2ada6d6832d0de4d633aacd997dc3a45
Gitweb: http://git.kernel.org/tip/1593843e2ada6d6832d0de4d633aacd997dc3a45
Author: Ingo Molnar <mingo@...e.hu>
AuthorDate: Mon, 6 Jun 2011 12:13:40 +0200
Committer: Ingo Molnar <mingo@...e.hu>
CommitDate: Mon, 6 Jun 2011 12:13:40 +0200
x86-64, vsyscalls: Rename UNSAFE_VSYSCALLS to COMPAT_VSYSCALLS
Linus pointed out that the UNSAFE_VSYSCALL naming was inherently
bad: it suggests that there's something unsafe about enabling them,
while in reality they only have any security effect in the presence
of some *other* security hole.
So rename it to CONFIG_COMPAT_VSYSCALL and fix the documentation
and Kconfig text to correctly explain the purpose of this change.
Reported-by: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andy Lutomirski <luto@....edu>
Cc: Jesper Juhl <jj@...osbits.net>
Cc: Borislav Petkov <bp@...en8.de>
Cc: Arjan van de Ven <arjan@...radead.org>
Cc: Jan Beulich <JBeulich@...ell.com>
Cc: richard -rw- weinberger <richard.weinberger@...il.com>
Cc: Mikael Pettersson <mikpe@...uu.se>
Cc: Andi Kleen <andi@...stfloor.org>
Cc: Brian Gerst <brgerst@...il.com>
Cc: Louis Rilling <Louis.Rilling@...labs.com>
Cc: Valdis.Kletnieks@...edu
Cc: pageexec@...email.hu
Link: http://lkml.kernel.org/r/BANLkTimrhO8QfBqQsH_Q13ghRH2P%2BZP7AA@mail.gmail.com
Signed-off-by: Ingo Molnar <mingo@...e.hu>
---
Documentation/feature-removal-schedule.txt | 7 ++++---
arch/x86/Kconfig | 17 ++++++++++-------
arch/x86/kernel/vsyscall_64.c | 8 ++++----
arch/x86/kernel/vsyscall_emu_64.S | 2 +-
4 files changed, 19 insertions(+), 15 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 94b4470..4282ab2 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -601,10 +601,11 @@ Who: Laurent Pinchart <laurent.pinchart@...asonboard.com>
----------------------------
-What: CONFIG_UNSAFE_VSYSCALLS (x86_64)
+What: CONFIG_COMPAT_VSYSCALLS (x86_64)
When: When glibc 2.14 or newer is ubitquitous. Perhaps mid-2012.
-Why: Having user-executable code at a fixed address is a security problem.
- Turning off CONFIG_UNSAFE_VSYSCALLS mostly removes the risk but will
+Why: Having user-executable syscall invoking code at a fixed addresses makes
+ it easier for attackers to exploit security holes.
+ Turning off CONFIG_COMPAT_VSYSCALLS mostly removes the risk but will
make the time() function slower on glibc versions 2.13 and below.
Who: Andy Lutomirski <luto@....edu>
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 79e5d8a..30041d8 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1646,20 +1646,23 @@ config COMPAT_VDSO
If unsure, say Y.
-config UNSAFE_VSYSCALLS
+config COMPAT_VSYSCALLS
def_bool y
- prompt "Unsafe fast legacy vsyscalls"
+ prompt "Fixed address legacy vsyscalls"
depends on X86_64
---help---
Legacy user code expects to be able to issue three syscalls
- by calling fixed addresses in kernel space. If you say N,
- then the kernel traps and emulates these calls. If you say
- Y, then there is actual executable code at a fixed address
- to implement time() efficiently.
+ by calling a fixed addresses. If you say N, then the kernel
+ traps and emulates these calls. If you say Y, then there is
+ actual executable code at a fixed address to implement time()
+ efficiently.
On a system with recent enough glibc (probably 2.14 or
newer) and no static binaries, you can say N without a
- performance penalty to improve security
+ performance penalty to improve security: having no fixed
+ address userspace-executable syscall invoking code makes
+ it harder for both remote and local attackers to exploit
+ security holes.
If unsure, say Y.
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index 285af7a..27d49b7 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch/x86/kernel/vsyscall_64.c
@@ -116,7 +116,7 @@ static int al_to_vsyscall_nr(u8 al)
return -1;
}
-#ifdef CONFIG_UNSAFE_VSYSCALLS
+#ifdef CONFIG_COMPAT_VSYSCALLS
/* This will break when the xtime seconds get inaccurate, but that is
* unlikely */
@@ -138,9 +138,9 @@ vtime(time_t *t)
return result;
}
-#endif /* CONFIG_UNSAFE_VSYSCALLS */
+#endif /* CONFIG_COMPAT_VSYSCALLS */
-/* If CONFIG_UNSAFE_VSYSCALLS=y, then this is incorrect for vsyscall_nr == 1. */
+/* If CONFIG_COMPAT_VSYSCALLS=y, then this is incorrect for vsyscall_nr == 1. */
static inline unsigned long vsyscall_intcc_addr(int vsyscall_nr)
{
return VSYSCALL_START + 1024*vsyscall_nr + 2;
@@ -202,7 +202,7 @@ void dotraplinkage do_emulate_vsyscall(struct pt_regs *regs, long error_code)
break;
case 1:
-#ifdef CONFIG_UNSAFE_VSYSCALLS
+#ifdef CONFIG_COMPAT_VSYSCALLS
warn_bad_vsyscall(KERN_WARNING, regs, "bogus time() vsyscall "
"emulation (exploit attempt?)");
goto sigsegv;
diff --git a/arch/x86/kernel/vsyscall_emu_64.S b/arch/x86/kernel/vsyscall_emu_64.S
index 7ebde61..2d53e26 100644
--- a/arch/x86/kernel/vsyscall_emu_64.S
+++ b/arch/x86/kernel/vsyscall_emu_64.S
@@ -25,7 +25,7 @@ ENTRY(vsyscall_0)
ret
END(vsyscall_0)
-#ifndef CONFIG_UNSAFE_VSYSCALLS
+#ifndef CONFIG_COMPAT_VSYSCALLS
.section .vsyscall_1, "a"
ENTRY(vsyscall_1)
movb $0xce, %al
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists