linux-kernel - Re: VDSO gettimeofday() x86

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 16 Oct 2012 12:24:46 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	wilson self <wself00@...il.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: VDSO gettimeofday() x86_64 linux 3.2

On 10/16/2012 11:09 AM, wilson self wrote:
> I noticed recently that my get time of day calls are quite a bit
> slower than I would have expected; and it would see that a likely
> cause is that they are not going via vdso, but rather a system call.
> 
> In older kernels there was kernel.vsyscall64 parameter to enable them,
> but this seems to be gone in later kernel releases.  What config
> option or parameter might I be missing that could cause gettimeofday()
> to use the fallback methods?

That option is gone because it's treated as unconditionally true.  What
does /sys/devices/system/clocksource/clocksource0/current_clocksource
say?  The usual cause of this problem is a clocksource other than tsc or
hpet.  hpet is amazingly slow, though, and arguably the hpet vdso code
could be deleted because the syscall overhead is the least of your
worries if you're using the hpet for timing.

(Also, if you're doing the call yourself instead of using libc, make
sure you're using the vdso and not the old vsyscall.  The vsyscall (call
direct to 0xffffffffff600000) is the slowest possible way to read the
time -- it's several times slower than the syscall on my box.  This is
mostly intentional.

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