Re: Fw: Questions about VDSO

[Benjamin Herrenschmidt <benh at au1 dot ibm dot com>]

On Thu, 2004-11-04 at 19:26 -0800, Roland McGrath wrote:

> > The main issue I had last time I tried to push the subject of
> > interfacing the PPC vDSO with glibc was the actual calling convention
> > from userland to the vDSO. Because our ABI has OPD decscriptors for
> > function calls and those contain absolute addresses (at least on ppc64),
> > that means that if we use normal linking against the vDSO (which
> > actually works), the vDSO has to be mapped in userland at the same
> > virtual address it was "linked" for. That excludes randomization. 
> 
> There is little enough relocation to be done, you can do it automagically
> in the kernel if you want to.

I could ... I mean, yes, I could from the kernel, do the mprotect, fixup
the OPD entries, thus triggering the COW, and mprotect back, yes, that's
sort-of duplicating what ld.so already knows how to do tho ..

> Things that need precise control should use PT_LOAD segments to reserve space.
> Your vdso mapping should not clobber any such reservations.

Ok, I need to look into this on the kenrel side.

> It doesn't make sense to automagically map a page read-only if it's only
> useful when modified.  If you want to do that, then provide it read/write
> in the first place.  Still then another syscall is required for relro,
> desireable safety.  It seems preferable to just have the kernel provide a
> read-only vdso that works.

No. there are reasons for having it ro in the first place: the vdso is
basically ro by default (and the last page of it, which contains a
special page of data shared by the kenrel, must never be COWed). In most
cases, I expect the vDSO to stay at it's native address (unless we
really intend to randomize all the time, not sure it makes much sense
for the vDSO itself tho) so no relocation is needed. I could map part of
it rw and part of it ro, but that would require having 2 VMAs, which
would add more overhead (though it's possible).

> > Another option is to have a non-normal calling convention to the vDSO.
> > This can be either the vDSO exporting "offsets" or  just 0-based OPDs
> > and having glibc/ld.so use special branch trampolines to call into it.
> > The disadvantage is that it will add overhead to calls that are
> > optimisations for perf critical things in the first place (like
> > gettimeofday, cache flush, memset/memcpy, etc...)
> 
> 
> > Ideally, it would be nice if we could define some kind of relocation &
> > appropriate symbol versioning (so glibc can still override the vDSO if
> > necessary) so that ld.so directly links the app calls to those routines
> > to the vDSO when it's available.
> 
> What exactly do you mean here?  The vDSO defines symbols and symbol
> versions just like any other DSO.  

Yes, but I've been explained that they were "after" glibc in the symbol
search path, that is, if the vdso defines gettimeofday(), the glibc
version would override it anyway, but then, I don't know the details of
how glibc & symbol versioning works.

> > ld.so itself need a non-link way to call into it as well (symbol lookup
> > + call via function pointers ?) for things like the cache flushing.
> 
> This doesn't really need to be something other than normal linking.

Ok, that's just ignorance on my side, but ld.so itself not a static
binary ? Can it link itself against the vDSO ?

> > So as you can see, there are plenty of issues to solve at this point.
> 
> Let's do what's clear first, and work incrementally.  If you now have a
> vdso with useful unwind info for signal trampolines, let's concentrate on
> making that work right.

Ok, I do have one. I posted the patch earlier but it may not apply
anymore, I'll revive it and post an updated version later today.

Ben.