Re: [RFC, PATCH] Fixup COMPAT_VDSO to work with CONFIG_PARAVIRT

[ebiederm@xmission.com (Eric W. Biederman)]

Jeremy Fitzhardinge <jeremy@goop.org> writes:

> Ingo Molnar wrote:
>> that's what is the case right now, but much of the intention behind the 
>> vma based vDSO is to enable per-process randomized vdso locations, and 
>> various distributions do that. So the 'modern' vDSO concept is very much 
>> relocatable.
>
> No, the point is that it never needs relocating.  The kernel can map it
> anywhere and userspace can cope.  Its only the broken glibcs which
> require relocation.

Ok.  So to summarize.
There are three ways of finding the VDSO.
- AT_SYSINFO
- AT_SYSINFO_EHDR
- known fixed address (see x86_64)

Currently it doesn't sound like you need to deal with the known fixed
address case but COMPAT_VDSO also provides that.

If userspace uses AT_SYSINFO the premise is that it is not expecting
not to need to perform any relocation processing.

If userspace uses AT_SYSINFO_EHDR it expects it needs to perform
relocation processing and fixes up whatever needs fixing up.

With the module code we have shown the kernel is capable of performing
relocation processing at times and it works.

So is it possible to simply relocate the normal vdso and fixup
it's program header so it shows that relocation is not necessary.
If you can do that and still export AT_SYSINFO so the problem user
space still runs you are good.  (If you can relocate the vdso
you should be able to relocate it anywhere).

Otherwise it probably just make sense to simply not export a VDSO
on those systems.

This would leave COMPAT_VDSO for the case where you must use one magic
fixed address, and if user space does not require that it means
COMPAT_VDSO could be completely removed.

Eric