Re: [RFC][PATCH] linux-2.6.2-rc2_vsyscall-gtod_B1.patch

[Jamie Lokier]

Ulrich Drepper wrote:
> Your entire scheme is based on this and therefore not worth the bits
> used to store it.  Your understanding of how and where syscalls are made
> and how ELF works is flawed.  There is no "group the syscalls nicely
> together", they are all over the place, inlined in many places.

That's a choice.  There is no reason why you cannot put the entry path
of all the stub functions called "read", "write" etc. in a special
section.  For syscalls inlined in larger functions, then it's
reasonable to avoid text relocation in those places and use an
indirect call as done now.  Surely there aren't too many of those,
though, because LD_PRELOAD libraries which override syscall stubs
rather depend on all normal calls to a syscall going through the stubs?

> there is no concept of weak aliases in dynamic linking.  Finding all
> the "aliases" requires lookups by name for now more than 200 syscall
> names and growing.

See Ingo's post.

> Prelinking can help if it is wanted, but if the vDSO address is
> changed or randomized (this is crucial I'd say) or the vDSO is not
> setup up for a process, the full price has to be paid.

I agree; it is not reasonable to depend on prelinking.

> With every kernel change the whole prelinking has to be redone.

Not really, that's an implementation limitation, there's no reason to
prelink the entire system just to alter the jumps in libc.so on those
occasions when a new kernel is run.  If vDSO randomisation is per boot
rather than per task (because the latter implies an MSR write per
context switch), then a libsyscall.so can be patched at boot time.

Yes I know, extravagent ideas, just wanted to write them for folk to
be aware of the possibilities.

> If gettimeofday() is the only optimized syscall, just add a simple
> 
>   cmp $__NR_gettimeofday, %eax
>   je  __vsyscall_gettimeofday
> 
> to the __kernel_vsyscall code.

That does seem to be a very practical answer for now :)

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/