vdso: -V3

this is the third, reworked version of the VDSO randomization (and 
hypervisor-helping) patchset. In particular FC1 is booting now fine, via 
the CONFIG_COMPAT_VDSO (default=y) kernel option.

besides the security implications, this feature also helps debuggers, 
which can COW a vma-backed VDSO just like a normal DSO and can thus do 
single-stepping and other debugging features.

It's good for hypervisors (Xen, VMWare) too, which typically live in the 
same high-mapped address space as the VDSO, hence whenever the VDSO is 
used, they get lots of guest pagefaults and have to fix such guest 
accesses up - which slows things down instead of speeding things up (the 
primary purpose of the VDSO).

If the CONFIG_COMPAT_VDSO option is disabled then there is no 
(user-visible) high VDSO mapping, the VDSO resides in a low-mapped vma.

If the CONFIG_COMPAT_VDSO option is enabled then the VDSO is prelinked 
at kernel build time and is high-mapped to the usual 0xffffe000 address. 
The same page is also installed into a low vma - sharing all the 
codepath with the !compat code. Signal returns, sysexit returns and 
syscall addresses point to the low mapping - only the DSO metadata 
header (AT_SYSINFO_EHDR) points to the high address.

I have checked that the FC1 version of glibc (which is a pre-release 
2.3.2 glibc, i.e. pretty much the worst-case scenario in terms of VDSO 
relocation bugs) still works fine and the system boots up. Likewise, FC1 
still boots even if CONFIG_COMPAT_VDSO is disabled, if the vdso=0 boot 
option is specified.

I have also included a print-fatal-signals add-on patch: it will now 
print out the "/proc/*/maps" file of segfaulting processes - this was 
very helpful when debugging the VDSO patchset, and can be useful to 
debug other early-bootup application-crash problems too.

	Ingo