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  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 22 May 2014 16:04:22 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>, Linux API <linux-api@...r.kernel.org>
Subject: Pondering per-process vsyscall disablement

It would be nice to have a way for new programs to declare that they
don't need vsyscalls.  What's the right way to do this?  An ELF header
entry in the loader?  An ELF header entry in the program?  A new
arch_prctl?

As background, there's an old part of the x86_64 ABI that allows
programs to do gettimeofday, clock_gettime, and getcpu by calling to
fixed addresses of the form 0xffffffffff600n00 where n indicates which
of those three syscalls is being invoked.  This is a security issue.

Since Linux 3.1, vsyscalls are emulated using NX and page faults.  As
a result, vsyscalls no longer offer any performance advantage over
normal syscalls; in fact, they're much slower.  As far as I know,
nothing newer than 2012 will attempt to use vsyscalls if a vdso is
present.  (Sadly, a lot of things will still fall back to the vsyscall
page if there is no vdso, but that shouldn't matter, since there is
always a vdso.)

Despite the emulation, they could still be used as a weird form of ROP
gadget that lives at a fixed address.  I'd like to offer a way for new
runtimes to indicate that they don't use vsyscalls so that the kernel
can selectively disable emulation and remove the fixed-address
executable code issue.


--Andy
--
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