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:36:17 -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 3:03 PM, Andy Lutomirski <> wrote:
> 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
> hideous.
> #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.

I'm testing a patch.  If it seems to work, I'll send it out.  It's a
big cleanup.

> --Andy

Andy Lutomirski
AMA Capital Management, LLC
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