Bug 12813 - Linux x86_64: glibc should prefer the vDSO over vsyscalls
Summary: Linux x86_64: glibc should prefer the vDSO over vsyscalls
Alias: None
Product: glibc
Classification: Unclassified
Component: libc (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Ulrich Drepper
Depends on:
Reported: 2011-05-26 21:24 UTC by Andy Lutomirski
Modified: 2014-06-27 13:15 UTC (History)
0 users

See Also:
Last reconfirmed:
fweimer: security-


Note You need to log in before you can comment on or make changes to this bug.
Description Andy Lutomirski 2011-05-26 21:24:41 UTC
As of right now, all functionality in the vsyscall page is available through the vDSO on x86_64.  The missing function was time(), but that landed here:


and is faster than the vsyscall version because of


Currently (AFAICT), glibc will use the gettimeofday vsyscall in static builds due to:

#ifdef SHARED
        movq    __vdso_gettimeofday(%rip), %rax
        PTR_DEMANGLE (%rax)
        movq    $VSYSCALL_ADDR_vgettimeofday, %rax

and will unconditionally use the vsyscall versions of time and getcpu.

It would be nice to kill off the vsyscall page entirely and replace it with some kind of emulation layer that keeps old code working (with a performance penalty) but doesn't leave a syscall instruction sitting at a fixed address.

Before doing that, glibc should stop using it in new code, at least on kernels that have a vDSO.
Comment 1 Andy Lutomirski 2011-05-27 15:04:46 UTC
As an added benefit of the vDSO over vsyscalls: things like UML can replace the vDSO if they want to.  This means that sched_getcpu and gettimeofday would have a better chance of returning the guest's answer (instead of the host's) on UML.
Comment 2 Ulrich Drepper 2011-05-28 12:13:32 UTC
I did add code to use the vdso in dynamically linked code.  But I don't change the static code.  Just go ahead, make the vsyscalls slow.  Noone should use statically linked code at all.  It's OK to be slower.