This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: kernel DSO
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Alan Modra <amodra at bigpond dot net dot au>
- Cc: libc-alpha at sources dot redhat dot com, Steve Munroe <sjmunroe at us dot ibm dot com>, Benjamin Herrenschmidt <benh at kernel dot crashing dot org>, Paul Mackerras <paulus at samba dot org>
- Date: Tue, 14 Sep 2004 09:03:28 +0200
- Subject: Re: kernel DSO
- References: <20040914064723.GJ21519@bubble.modra.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Tue, Sep 14, 2004 at 04:17:23PM +0930, Alan Modra wrote:
> So, my question is: Does this idea have some fundamental flaw that
> makes it unacceptable? The benefits should be clear: A faster call
> path, and no jumps to magic addresses since the kernel DSO exports
> a proper symbol table.
I see two problems with this.
One is symbol versioning, glibc suddenly looses control of the symbol
versions which the vDSO is overriding, so coming up with a new symbol
version for one of these functions is hard.
The other is that it badly clashes with prelinking.
Kernel really wants to randomize the vDSO (otherwise even in PIEs
you can exploit things by jumping to the known addresses in the vDSO)
and the vDSO is not under prelink's control, so if say memcpy
is in the vDSO, suddenly all relocations against memcpy would be
prelink conflicts. Even if the vDSO is not randomized,
assuming the vDSO layout is different between different CPUs
and/or kernel versions, prelink can't modify its dynamic tags
and therefore it can't determine whether it was prelinked
against the exact same vDSO or a different one.
Jakub