On Thu, May 22, 2014 at 7:44 PM, Marian Marinov <m...@1h.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 05/23/2014 02:04 AM, Andy Lutomirski wrote: >> 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. >> >> > Wouldn't it be more useful if the check is against a bitmask added as > extended attribute for that executable? > This way the administrators and will have the flexibility to simply add the > new attribute to the executable.
I don't think this should be something configured by the administrator, unless the administrator is the builder of a kiosky thing like Chromium OS. In that case, the administrator can use vsyscall=none. I think this should be handled by either libc or the toolchain, hence the suggestions of a syscall or an ELF header. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
