linux-kernel - Re: [PATCH v2] x86: Remove compat vdso support

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: <20140311083744.GA27605@gmail.com>
Date:	Tue, 11 Mar 2014 09:37:44 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...ux.intel.com>,
	the arch/x86 maintainers <x86@...nel.org>,
	Stefani Seibold <stefani@...bold.net>,
	Andreas Brief <Andreas.Brief@...de-schwarz.com>,
	Martin Runge <Martin.Runge@...de-schwarz.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Dave Jones <davej@...hat.com>
Subject: Re: [PATCH v2] x86: Remove compat vdso support


* Andy Lutomirski <luto@...capital.net> wrote:

> [...]
> 
> Currently there are three options: sane vDSO, no vDSO, and OpenSuSE 
> 9-compatible vDSO.  The latter is a mess to maintain and breaks ASLR 
> (even for users of modern glibc), and having a vDSO is apparently 
> important enough that people are willing to pay to enhance it.  The 
> default is OpenSuSE 9-compatible vDSO, which is IMO an odd choice.

The 'odd choice' was to not break the ABI by default...

> ISTM the right solution is to make OpenSuSE 9 users turn off the 
> vDSO (which is a performance hit for them, but not a correctness 
> issue) and let everyone else have a simpler kernel that has no ASLR 
> issues.

Could we just remove the option and automagically disable the vdso on 
OpenSuSE-9, without any boot flags? Is the segfault distinctive enough 
to base a disable-vdso quirk on, either to disable the vdso, or to map 
it into the compatibility position on demand?

That would remove most of this complication. Being somewhat slower on 
an old distro with a new kernel is perfectly OK. The question is, can 
this be done easily enough - chances are that it cannot be done.

Thanks,

	Ingo
--
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/