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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 15 Jun 2014 11:39:54 -0700
From:	"H. Peter Anvin" <>
To:	Andy Lutomirski <>,
	Andi Kleen <>
CC:	Rich Felker <>,
	Mikael Pettersson <>,
	Russ Cox <>,
	Linux API <>,
	Ian Taylor <>,
	"" <>,
	X86 ML <>
Subject: Re: [RFC 0/2] __vdso_findsym

Symbol versioning so we can rev the ABI and still provide backwards compatibility.  Weak symbols so the libc can override symbols if it considers it appropriate.  This is a good thing.

On June 15, 2014 11:20:41 AM PDT, Andy Lutomirski <> wrote:
>cc: Andi Kleen, who designed the vdso
>On Sun, Jun 15, 2014 at 10:57 AM, H. Peter Anvin <> wrote:
>> On 06/15/2014 10:40 AM, Andy Lutomirski wrote:
>>> To be clear, I have no desire whatsoever to give the vdso an actual
>>> ELF parser or anything else that userspace should be providing
>>> I think that a special-purpose vdso parser in the vdso makes some
>>> sense, though, since userspace might otherwise provide one for the
>>> sole purpose of parsing the vdso.
>>> And there's plenty of reasons that having the vdso be an ELF image
>>> useful.  For one thing, gdb can take advantage of it.  For another,
>>> CRIU is parsing it for a rather different reason, and something like
>>> __vdso_findsym won't fill that need.
>>> Also, given the general lack of a comprehensible specification of
>>> the GNU flavor of the ELF format actually is [1], there's something
>>> be said for reducing the proliferation of ELF parsers.  glibc and
>>> binutils are quite unlikely to become incompatible with each other,
>>> but I sincerely doubt that anyone from binutils land is likely to
>>> review (and maintain!) my ELF parser, Go's, or a hypothetical future
>>> ELF parser from any of the other glibc-less things.  If those things
>>> use one that's in the kernel, then it's easy for the kernel to
>>> guarantee that each vdso image can successfully parse itself.
>>> [1] The only comprehensible description of the GNU hash extension
>>> I could find is on Oracle's blog (!)
>> Yes, but that is why we provide the standard SysV hash.  The GNU hash
>> not too bad, but you're absolutely right the documentation stinks.
>> Providing a simple symbol lookup is an opportunistic thing, and might
>> useful that way, and only because (as you say) the version in the
>> would only need to be guaranteed to parse a single data structure --
>> that same vdso.
>> On the other hand, it better work, correctly, in every version of the
>> kernel, so I believe it will need to be done such that it is either
>> correct by construction or gets self-tested during the build process
>> it errors out on failure.
>I was thinking of adding something to selftests that would check that
>__vdso_findsym can find every exported symbol, check that it can't
>find the ones it shouldn't find, and call it on a bunch of garbage
>strings to make sure it rejects them.
>> One simple way to do correct by construction
>> would be to do the "vdso entry point by index" -- a new kind of
>> call numbers, in effect, as much as it has shades of Windows DLL with
>> their "ordinal numbers".
>It's certainly easy.  It's a little gross, and I sort of feel bad
>about having two parallel ways of referring to a vdso function -- one
>used by ELF parsers and one used by the new thing.  Using an array
>also wins on speed and code size.  *sigh* -- I'm torn on this one.
>Do you know why the vdso uses symbol versioning and weak symbols in
>the first place?  This seems to date back all the way to the beginning
>(2aae950b21e4bc789d1fc6668faf67e8748300b7).  If we're going to add a
>new way to find vdso symbols, I would like to at least drop support
>for versions.

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