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, 2004-09-14 at 19:08, Jakub Jelinek wrote:

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

Ok, so how does it work with glibc at the moment on x86 ? glibc
uses special stubs to get into the vDSO and isn't "linked" against it ?

I'm still not sure what impact the code I mentioned in rtld.c has, from
my understanding, the simple presence of a vDSO would cause that code
to set prelink = 0 for the rest of dl_main()... 

> BTW, how many different memcpy etc. CPU variants do you expect?

It depends. Not too many on ppc64, a lot more on ppc32, at least for
now, it may blow up on ppc64 as well in the future.

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

Yes. We already have quite a bit of combinations coming, especially if
you count ppc32, and it's proven easier to update the kernel for a new
CPU (has to be done anyways) than to update glibc...

Also, it's difficult to explain the variety just with AT_PLATFORM... For
example, if we set that on CPU "family", like POWER3, POWER4, RS64,
POWER5, do we want the G5 to be a POWER4 or a separate selection ? It
has some commonities with POWER4 for some things, but then, it's
different for others (like cache characteristics)...

Finally, one of the reason for these is also to possibly work around CPU
bugs on some of the functions (like the 4xx familly requiring a sync in
the atomic operations). In that case, we may want fine grained control
by CPU revision even.

It seems a lot easier, at least to me, to provide this via the kernel.
Note that the first implementation planned may not contain all of this
yet though. We'd like to have something merged & working with the
minimum, that is the signal trampolines, userland gettimeofday, and the
cache flush/invalidate asap so it might make it into some distro ...
Only the later will be CPU specific (mostly atm because POWER5 doesn't
require it, the icache snoops on those).

The optimized memcpy & friends will come later.

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

Ok. Makes sense. So prelink can still do some kind of randomization
itself, so that 2 boxes don't have everything at the same address, but
once prelinked, things stay fixed on a given install.

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

Ok.

Well, I'm open to all suggestions regarding how to deal with entry to the
vDSO, as some of you have already seen. It exports "normal" symbols for now,
which means it just works to link against it on ppc32, but not on ppc64 unless
relocation is enabled (or it's always loaded at the same address, but then,
we need a phdr allowing some specific apps to require it to be elsehwere, so
that is not an option).

A possibility would be to 1) always call through glibc, and 2) have glibc
use special asm stubs to call into the vDSO. The problem is that perf critical
functions like memcpy would end up beeing called via 2 or 3 level of indirection
(I know our ABI isn't terrific in this regard, but we end up making things
somewhat worse here ...)

Also, one last note. The vDSO I've posted so far lacks one of the
functions listed above, which is the cache flush/inval. I'll add this next
week. This one will also have to be used by ld.so itself of course, replacing
the current built-in ones, and I suppose ld.so itself cannot just "link"
against a .so like the vdso so we would have to do some manual scrubbing for
symbols & branch trampolines anyway.

Ben.


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