linux-kernel - Re: [PATCH v4 0/6] Micro-optimize vclock

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]

Message-ID: <alpine.LFD.2.02.1105180839370.3078@ionos>
Date:	Wed, 18 May 2011 09:30:22 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Andrew Lutomirski <luto@....edu>
cc:	Andi Kleen <andi@...stfloor.org>, Ingo Molnar <mingo@...e.hu>,
	x86@...nel.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Borislav Petkov <bp@...64.org>
Subject: Re: [PATCH v4 0/6] Micro-optimize vclock_gettime

On Tue, 17 May 2011, Andrew Lutomirski wrote:
> On Tue, May 17, 2011 at 6:59 PM, Thomas Gleixner <tglx@...utronix.de> wrote:
> > Furthermore any halfways up to date deployemnt is using VDSO for
> > obvious reasons and the archaic stuff which might be affected is not
> > using a recent kernel at all (except for akpm on his retro laptop, but
> > that "performance penalty" is probably the least of his worries).
> 
> Sadly that's not quite true.  glibc git right now contains this:
> 
> ENTRY (__gettimeofday)
>         /* Align stack.  */
>         sub     $0x8, %rsp
>         cfi_adjust_cfa_offset(8)
> #ifdef SHARED
>         movq    __vdso_gettimeofday(%rip), %rax
>         PTR_DEMANGLE (%rax)
> #else
>         movq    $VSYSCALL_ADDR_vgettimeofday, %rax
> #endif
>         callq   *%rax

I know that, but again: Are statically linked binaries a real issue ?
 
> And time() and sched_getcpu() call the vsyscall page unconditionally.

Dammit, time() is a real problem. I missed that and thought that it's
gettimeofday() alone for the static case. sched_getcpu() is nothing to
worry about.

> We should either declare CLOCK_REALTIME_COARSE to be acceptable for
> time() or add a new vDSO call.

Separate call.

> IMO we should put a note in feature-removal-schedule.txt, add vsyscall
> emulation as a config option for 2.6.41 but leave it turned off by
> default, and turn it on by default (or just remove the old code) in
> 2.6.43 or so.  That'll give glibc a chance to stop generating *new*
> static binaries that call it.
> 
> I'm not volunteering to dig around the libdl stuff to fix it myself.
> 
> klibc doesn't seem to use vsyscalls or the vDSO.  I haven't looked at
> uclibc, and I don't think that Bionic has any released version on
> x86_64.

uclibc is safe as well. The VSYSCALL usage is in the futex code, but
is conditional and not used on current kernels. That code is copied
from glibc.

Thanks,

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