| 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 13:27:25 -0400 From: Andy Lutomirski <luto@....EDU> To: x86@...nel.org, Ingo Molnar <mingo@...e.hu> Cc: pageexec@...email.hu, Mikael Pettersson <mikpe@...uu.se>, "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...ux-foundation.org>, Andy Lutomirski <luto@....edu> Subject: [PATCH 3/3] x86-64: Clarify CONFIG_COMPAT_VSYSCALLS text Enough people are confused about whether CONFIG_COMPAT_VSYSCALLS=n breaks binary compatibility that we should make it harder to be confused. So make it more clear what's going on. The new text is a slight lie in that CONFIG_COMPAT_VSYSCALLS could make it slightly harder to exploit *kernel* bugs once the kernel address layout is randomized, but I mentioning that in the help text might just cause more confusion Signed-off-by: Andy Lutomirski <luto@....edu> --- Documentation/feature-removal-schedule.txt | 11 +++++++---- arch/x86/Kconfig | 27 +++++++++++++++------------ 2 files changed, 22 insertions(+), 16 deletions(-) diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 4282ab2..ef5d1e9 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -602,11 +602,14 @@ Who: Laurent Pinchart <laurent.pinchart@...asonboard.com> ---------------------------- What: CONFIG_COMPAT_VSYSCALLS (x86_64) -When: When glibc 2.14 or newer is ubitquitous. Perhaps mid-2012. +When: When glibc 2.14 or newer is ubiquitous. Perhaps 2013. 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. + it easier for attackers to exploit security holes. Turning off + CONFIG_COMPAT_VSYSCALLS reduces the risk without breaking binary + compatibility but will make the time() function slower on glibc + versions 2.13 and below. + + We may flip the default setting to N before 2013. Who: Andy Lutomirski <luto@....edu> ---------------------------- diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 30041d8..17d99bc 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -1648,24 +1648,27 @@ config COMPAT_VDSO config COMPAT_VSYSCALLS def_bool y - prompt "Fixed address legacy vsyscalls" + prompt "Fast legacy sys_time() vsyscall" depends on X86_64 ---help--- - Legacy user code expects to be able to issue three syscalls - 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. + Glibc 2.13 and older, statically linked binaries, and a few + other things use a legacy ABI to implement time(). - 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: having no fixed - address userspace-executable syscall invoking code makes - it harder for both remote and local attackers to exploit - security holes. + If you say N here, the kernel will emulate that interface in + order to make certain types of userspace bugs more difficult + to exploit. This will cause some legacy software to run + slightly more slowly. + + If you say Y here, then the kernel will provide native code to + allow legacy programs to run without any performance impact. + This could make it easier to exploit certain types of + userspace bugs. If unsure, say Y. + NOTE: disabling this option will not break any ABI; the kernel + will be fully compatible with all binaries either way. + config CMDLINE_BOOL bool "Built-in kernel command line" ---help--- -- 1.7.5.2 -- 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