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 06:19:38PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2004-09-14 at 18:01, Alan Modra wrote:
> > On Tue, Sep 14, 2004 at 05:40:58PM +1000, Benjamin Herrenschmidt wrote:
> > > The vdso will be almost identical... except the .dynsym table in the
> > > vdso is "patched" by the kernel at boot for functions like memcpy
> > > to point to memcpy_cpumodel, and that sort of thing.
> > 
> > Which would mean a prelink conflict.  Anything that calls memcpy will
> > need to be relocated, unless you want to commit to a fixed memory
> > location for memcpy in the vDSO.  I certainly wouldn't want that..
> 
> Well... no, on a single config, the fixup would be the same all the
> time (unless the kernel version is changed or the machine itself
> is changed, that is different CPU).
> So unless we do randomizing, we need one prelink pass after install to
> get the symbols right.

Prelink needs to modify each shared library so that it can start
applications that link against those libraries faster.
Particularly, it needs to apply all relocations, relocate the library to
chosen address and add two dynamic tags into it.
I don't see how that's possible with vDSO.

BTW, how many different memcpy etc. CPU variants do you expect?
Are you aware that you can just set AT_PLATFORM by the kernel and
it the number of CPU variants is reasonably small (at least the number
of CPU variants with big enough user base to care about them and big enough
advantage of CPU specific routines) and glibc can handle optimized routines
itself with its current infrastructure?

> What I don't understand is how randomizing + prelink can work together

Kernel by default randomizes unless a shared library or PIE has a preferred
address (== it has been prelinked).
If the executable is non-prelinked PIE (PIEs are not prelinkable ATM, but
that could change with some amount of work), kernel (for ld.so, ld.so for
the other shared libraries) don't honor the preferred address and randomize
anyway.
This means, on non-prelinked system, everything is randomized.
On prelinked systems, security exposed applications (built as PIEs) are
randomized, other programs are not randomized and start faster.

	Jakub


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