This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: kernel DSO


On Tue, Sep 14, 2004 at 09:03:28AM +0200, Jakub Jelinek wrote:
> 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.

I don't see how this is really different from a user supplying a library
that overrides some glibc functions.

> 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.

Prelink may well be a fly in the ointment.  As you say, there isn't any
way that prelink can set dynamic tags.  So it seems like we'd lose some
time in prelinked app startup for conflict resolution if we want to
avoid an extra jump getting to our optimised memcpy.  That extra jump
might be significant for apps (and benchmarks) that do lots of string
manipulation.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]