Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3)

[Jakub Jelinek <jakub@redhat.com>]

On Wed, Mar 03, 2004 at 06:54:49PM -0800, john stultz wrote:
> On Wed, 2004-03-03 at 18:47, Andrea Arcangeli wrote:
> > And sysenter is at a fixed address in 2.6 x86 too (it doesn't even
> > change between different kernel compiles).
> 
> Actually, the 4G patch pushes vsysenter down a page, and glibc seems to
> handle this properly.

But the 4G/4G patch relinks the vDSO to the address it uses, this is no
big problem for glibc which of course doesn't use hardcoded address but
reads AT_SYSINFO{,_EHDR} values kernel passes to it.

But the fixed vDSO location is a problem, exploits certainly appreciate
a fixed address at which they with high probability can enter the kernel.

Ingo Molnar recently wrote a patch to randomize the vDSO address on
IA-32.  Unfortunately it revealed some bugs in glibc where ld.so did not
handle properly vDSOs linked to one address, but mmaped to a different one
(which is a must if kernel wants to share one vDSO page for each process).
So now the problem is if kernel randomizes vDSO, it will not even boot
with glibcs >= 2003-04-22 and <= 2004-02-27.  There are 2 possible solutions
for this IMHO:
1) tell users of the glibc's which don't handle this they must upgrade glibc
first before booting a newer kernel and add kernel cmdline option to turn
vDSO off, so that a user can turn it off, upgrade glibc and then on next
boot use vDSO again
2) start using a different AT_SYSINFO_* value (just one is enough,
ATM AT_SYSINFO is ((ElfNN_Ehdr *)AT_SYSINFO_EHDR)->e_entry), stop using
the old 2 values.  This would mean old glibcs will stop using vDSO, but hey,
it is just an optimization.  Upgrading glibc would use vDSO again.

	Jakub