linux-kernel - Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <CALCETrUpVYrUfn=cDGtrxg3pDBonVmiK59iAZL1nQxCV0v3wmA@mail.gmail.com>
Date:	Mon, 10 Mar 2014 15:03:12 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Stefani Seibold <stefani@...bold.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Andreas Brief <Andreas.Brief@...de-schwarz.com>,
	Martin Runge <Martin.Runge@...de-schwarz.com>
Subject: Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

On Mon, Mar 10, 2014 at 2:53 PM,  <stefani@...bold.net> wrote:
> Zitat von Linus Torvalds <torvalds@...ux-foundation.org>:
>
>> On Mon, Mar 10, 2014 at 2:25 PM,  <stefani@...bold.net> 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.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/