linux-kernel - Re: [RFC 0/2] __vdso

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: <20140616145618.GZ179@brightrain.aerifal.cx>
Date:	Mon, 16 Jun 2014 10:56:19 -0400
From:	Rich Felker <dalias@...c.org>
To:	Ian Lance Taylor <iant@...ang.org>
Cc:	Andi Kleen <andi@...stfloor.org>,
	Andy Lutomirski <luto@...capital.net>,
	"H. Peter Anvin" <hpa@...or.com>,
	Mikael Pettersson <mikpelinux@...il.com>,
	Russ Cox <rsc@...ang.org>,
	Linux API <linux-api@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	X86 ML <x86@...nel.org>
Subject: Re: [RFC 0/2] __vdso_findsym

On Mon, Jun 16, 2014 at 07:08:50AM -0700, Ian Lance Taylor wrote:
> On Sun, Jun 15, 2014 at 7:36 PM, Andi Kleen <andi@...stfloor.org> 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?

This is my sentiment as well, but I think you've stated it better than
I have.

Also note that, if the vdso is providing a "lookup the address of a
magic function by name" function, it need not be a full ELF parser,
i.e. it doesn't need to be able to deal with any ELF files except the
vdso provided by the current kernel. This probably allows the parser
to be considerably smaller; for example, all the version stuff can be
omitted unless the actual kernel in use provides multiple symbol
versions.

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