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:	Mon, 16 Jun 2014 07:08:50 -0700
From:	Ian Lance Taylor <>
To:	Andi Kleen <>
Cc:	Andy Lutomirski <>,
	"H. Peter Anvin" <>, Rich Felker <>,
	Mikael Pettersson <>,
	Russ Cox <>,
	Linux API <>,
	"" <>,
	X86 ML <>
Subject: Re: [RFC 0/2] __vdso_findsym

On Sun, Jun 15, 2014 at 7:36 PM, Andi Kleen <> wrote:
> I haven't looked into this in detail, but my initial assumption would
> be that it wouldn't be useful to add new vdso interfaces just for Go.
> After all would you really want to force ever Go user to upgrade their
> kernel just to get fast fime? So it has to work with whatever is already
> there anyways.

Go works fine with the current interface.  There was, arguably, a bug
in Go's old implementation in that it assumed that the vDSO would have
a normal symbol table.  That bug has already been fixed.

I think this issue started when some of the Go developers questioned
why the kernel needed to provide a very complex interface--parsing an
ELF shared shared library--for very simple functionality--looking up
the address of a magic function.  This approach has required special
support not just in Go, but also in the dynamic linker and gdb, and
does not work well for statically linked binaries.  The support in gdb
is perhaps a good idea, but elsewhere it does not make sense.

So why not provide a simple interface?

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