It looks 2.6.18 (on i386 only) changes the "vdso" memory page to be
mapped at a random location in every process's address space, rather
than at a fixed address. ("for security!"). This likely completely
screws over anyone who wants to reliably allocate memory at a fixed
address, such as sbcl.
Luckily there is a /proc switch to turn vdso mapping off...but that's
system-wide. Oh, and also, it looks like the part of the patch that
actually makes vdso_enabled *work* was omitted. Woo.
Also note that the CONFIG_COMPAT_VDSO option doesn't move the vdso to
the high place (and thus fix this problem), it only makes it appear
Anyhow, I've not actually tried i386 2.6.18, so maybe it's not as bad
as I think it is, but, it looks pretty bad. Luckily I'm using x86_64
almost exclusively now, so this won't burn me...but I'd recommend
anyone still on i386 not upgrade their kernel.
> Randomize the i386 vDSO
> Move the i386 VDSO down into a vma and thus randomize it. Besides
> the security implications (attackers cannot use the predictable
> high-mapped VDSO page as syscall trampoline anymore) this feature
> also helps debuggers, and it's good for hypervisors (Xen, VMWare)
> too. There's a new CONFIG_COMPAT_VDSO option, which provides
> support for older glibcs that still rely on a prelinked high-mapped
> VDSO. Newer distributions (using glibc 2.3.3 or later) can turn
> this backwards-compatibility option off (recommended, for security
> reasons, as the features makes harder certain types of attacks).
> There is a new vdso=[0|1] boot option as well, and a runtime /proc/
> sys/vm/vdso_enabled sysctl switch, that allows the VDSO to be
> turned on/off