|| ||Ingo Molnar <firstname.lastname@example.org>|
|| ||Andrew Morton <email@example.com>|
|| ||[patch 0/3] vdso: -V3|
|| ||Tue, 23 May 2006 02:01:11 +0200|
|| ||Arjan van de Ven <firstname.lastname@example.org>,
Linus Torvalds <email@example.com>,
Zachary Amsden <firstname.lastname@example.org>, email@example.com,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org|
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.