From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754461AbaCKIhw (ORCPT ); Tue, 11 Mar 2014 04:37:52 -0400 Received: from mail-ea0-f169.google.com ([209.85.215.169]:51239 "EHLO mail-ea0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752787AbaCKIhs (ORCPT ); Tue, 11 Mar 2014 04:37:48 -0400 Date: Tue, 11 Mar 2014 09:37:44 +0100 From: Ingo Molnar To: Andy Lutomirski Cc: Linus Torvalds , "H. Peter Anvin" , the arch/x86 maintainers , Stefani Seibold , Andreas Brief , Martin Runge , Linux Kernel Mailing List , Dave Jones Subject: Re: [PATCH v2] x86: Remove compat vdso support Message-ID: <20140311083744.GA27605@gmail.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Lutomirski 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