Messages in this thread | | | From | Andy Lutomirski <> | Date | Fri, 23 May 2014 09:40:44 -0700 | Subject | Re: Pondering per-process vsyscall disablement |
| |
On Thu, May 22, 2014 at 7:44 PM, Marian Marinov <mm@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
| |