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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 15 Jun 2014 12:50:36 -0700
From:	Ian Lance Taylor <>
To:	"H. Peter Anvin" <>
Cc:	Andy Lutomirski <>,
	Andi Kleen <>,
	Rich Felker <>,
	Mikael Pettersson <>,
	Russ Cox <>,
	Linux API <>,
	"" <>,
	X86 ML <>
Subject: Re: [RFC 0/2] __vdso_findsym

On Sun, Jun 15, 2014 at 12:31 PM, H. Peter Anvin <> wrote:
> The weak symbols are well-known names.  The __vdso symbols are strong.

I see.  But I don't understand how this is supposed to work.  When I
link a program against gettimeofday, I get a reference to gettimeofday
with version GLIBC_2.2.5.  After all, I only link against; I
don't link against the vDSO.  The VDSO provides gettimeofday with
version LINUX_2.6.  Since those versions don't match, the gettimeofday
reference in my executable will not be satisfied by the definition in
the vDSO.  So at dynamic link time my program is always going to be
linked with the gettimeofday in, which will in turn call the
gettimeofday in the vDSO.

Am I missing something that makes the definition of gettimeofday with
version LINUX_2.6 in the vDSO useful?


> On June 15, 2014 12:22:17 PM PDT, Ian Lance Taylor <> wrote:
>>On Sun, Jun 15, 2014 at 12:14 PM, H. Peter Anvin <> wrote:
>>> If it doesn't, then you incur an additional indirection penalty.  The
>>strong __vdso symbol allows the libc wrapper to fall back to the vdso
>>implementation, the weak symbol allows three to be no wrapper at all.
>>This is good.
>>> The reason for changing ABI would be shifting types.  This is very
>>much how glibc manages transitions.
>>The purpose of symbol versioning is so that symbols with well known
>>names, like stat, can continue to use those same names while changing
>>types.  Both old and new programs can continue to use the name stat
>>and continue to work even though they use different types.
>>I don't see how this applies to the kernel VDSO.  Those symbols do not
>>use well-known names; they use names like __vdso_time.  If you change
>>the types used by those symbols, you can change the name as well.
>>What is the downside?
> --
> Sent from my mobile phone.  Please pardon brevity and lack of formatting.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists