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


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