Messages in this thread | | | Date | Thu, 4 Mar 2004 03:57:36 -0500 | From | Jakub Jelinek <> | Subject | Re: [RFC][PATCH] linux-2.6.4-pre1_vsyscall-gtod_B3-part3 (3/3) |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |