[patch 0/3] vdso: -V3

From: Ingo Molnar
Date: Mon May 22 2006 - 20:00:55 EST

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.

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/