lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Mar 2014 15:03:12 -0700
From:	Andy Lutomirski <>
To:	Stefani Seibold <>
Cc:	Linus Torvalds <>,
	"H. Peter Anvin" <>,
	Linux Kernel Mailing List <>,
	Andreas Brief <>,
	Martin Runge <>
Subject: Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

On Mon, Mar 10, 2014 at 2:53 PM,  <> wrote:
> Zitat von Linus Torvalds <>:
>> On Mon, Mar 10, 2014 at 2:25 PM,  <> wrote:
>>> This was discovered by me.
>> Sorry for the misattribution.
>>> But this is not a real solution, at least when vcpu function support
>>> will be added, then the code size will exceed the page size. Reserving
>>> two pages for the VDSO is a good option.
>> Quite frankly, there is no way in hell I will take a patch like that
>> for 3.14 any more, and I would argue against it for stable.
>> Now, if this problem never happens with current kernels (because it's
>> purely due to the patch in -tip), then I don't much care.
>> That said, I don't understand why we are even adding new features like
>> this to 32-bit mode in the first place, so if that patch is the sole
>> source of all this headache, then why not just throw the patch away?
> The patch is working. And for this current issue there is a solution i
> already
> announced.
> A dual VDSO: a one page sized VDSO for the compat mode which has only the
> syscall
> code and on multi page sized VDSO which is mapped into user space for the
> non compat
> mode.
> This will work and has no side effects.

IMO this is dumb.  I can think of two sensible solutions:

1. Get rid of compat vdso and replace it with no vdso at all.  This is
compatible with everything and requires almost no code :)

2. Fix compat vdso.  Give it as much space as needed, make the address
dynamic, and relocate it to the right place.

I see no legitimate reason to further increase the number of 32-bit
vdso images.  Three is already ridiculous, and adding more is IMO

#1 is actually a serious proposal.  To do it right, I think we should
rename the config option to CONFIG_BROKEN_GLIBC_VDSO, default it to n,
and make the help text clarify that this only affects certain
non-released glibc versions and that anyone building a new kernel is
highly unlikely to be affected.  Then make vdso=2 act just like
vdso=0.  CONFIG_BROKEN_GLIBC_VDSO just changes the default from vdso=1
to vdso=0.

Damn it, the number of users who (a) have a buggy copy of glibc, (b)
are using new kernels, and (c) are using CONFIG_COMPAT_VDSO as opposed
to, say, vdso=2 is probably very close to zero.  (These users will
have issues until they fix their config.)

The number of users who (a) have a buggy copy of glibc, (b) are using
new kernels, and (c) have cpus that derive significant benefit from
using a vdso instead of int 80 and care at all is probably also very
close to zero.

The maintenance burden of this piece of shite is empirically quite far
from zero.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists