From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753753AbaCKQyL (ORCPT ); Tue, 11 Mar 2014 12:54:11 -0400 Received: from mga11.intel.com ([192.55.52.93]:32160 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751244AbaCKQyI (ORCPT ); Tue, 11 Mar 2014 12:54:08 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,631,1389772800"; d="scan'208";a="489900308" Message-ID: <531F3F57.8090105@linux.intel.com> Date: Tue, 11 Mar 2014 09:52:39 -0700 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Andy Lutomirski CC: Linus Torvalds , "linux-kernel@vger.kernel.org" , Stefani Seibold , the arch/x86 maintainers , Dave Jones , Martin Runge , Andreas Brief Subject: Re: [PATCH v2] x86: Remove compat vdso support References: <531F365B.4060000@linux.intel.com> <531F3D02.30706@linux.intel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/11/2014 09:50 AM, Andy Lutomirski wrote: > Looking forward, would it be reasonable to have an extensible set of > flags that live in the ELF interpreter's headers somewhere that > indicate compatibility hacks that the program in question doesn't > need? There are at least two things I can think of: > > - no_compat_vdso32: indicates an interpreter that can load a modern > non-prelinked vdso > - no_vsyscall64: indicates that the libc will not attempt to call > into the vsyscall page on x86_64. > > I'm sure that there are more. Think PT_GNU_STACK but for more than > just the stack. > > If we do something like this, there should probably be a prctl or > similar that can change some of the flags at runtime, too. > This comes many years too late for this purpose. Such flags might have a use, but at this point it is rather meaningless, I think. -hpa