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:22:48 -0700
From:	Andy Lutomirski <>
To:	"H. Peter Anvin" <>
Cc:	Rich Felker <>,
	Mikael Pettersson <>,
	Russ Cox <>,
	Linux API <>,
	Ian Taylor <>,
	"" <>,
	X86 ML <>
Subject: Re: [RFC 0/2] __vdso_findsym

On Sun, Jun 15, 2014 at 11:20 AM, H. Peter Anvin <> wrote:
> On June 15, 2014 10:40:03 AM PDT, Andy Lutomirski <> wrote:
>>On Sun, Jun 15, 2014 at 10:05 AM, H. Peter Anvin <> wrote:
>>> On 06/15/2014 07:35 AM, Rich Felker wrote:
>>>> Arguably, it was a mistake for the kernel to expose a virtual ELF to
>>>> begin with, and it should just have exposed a "lookup function by
>>>> name" operation to begin with. Yes this can be done in userspace,
>>>> I see it more as a matter of "fixing a broken API design".
>>> What the fsck are you smoking?  There is immense value in providing a
>>> stable and very well-defined data structure, which also happens to be
>>> what dynamic linkers already want to consume.  Providing a helper for
>>> crippled libc applications has potential value.  Shaving a few
>>> bytes off static applications is a very weak argument, simply because
>>> is such a small fraction of the enormous cost of a static
>>> and static applications are problematic in a number of other ways,
>>> especially the lack of ability to fix bugs.
>>> Treating the kernel as an ersatz dynamic library for "static"
>>> applications is kind of silly -- after all, why not provide an entire
>>> libc in the vdso?  I have actually seen people advocate for doing
>>To be clear, I have no desire whatsoever to give the vdso an actual
>>ELF parser or anything else that userspace should be providing itself.
>>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 is
>>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 what
>>the GNU flavor of the ELF format actually is [1], there's something to
>>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 that
>>I could find is on Oracle's blog (!)
> Curious about this blog.  We do have a GNU hash implementation in Syslinux, too, for another reference.

FWIW, I bet that __vdso_findsym could be smaller if it used the GNU
hash.  Maybe it would save about the same amount of space that turning
on the GNU hash would take up.

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