[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <531F3F57.8090105@linux.intel.com>
Date: Tue, 11 Mar 2014 09:52:39 -0700
From: "H. Peter Anvin" <hpa@...ux.intel.com>
To: Andy Lutomirski <luto@...capital.net>
CC: Linus Torvalds <torvalds@...ux-foundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Stefani Seibold <stefani@...bold.net>,
the arch/x86 maintainers <x86@...nel.org>,
Dave Jones <davej@...hat.com>,
Martin Runge <Martin.Runge@...de-schwarz.com>,
Andreas Brief <Andreas.Brief@...de-schwarz.com>
Subject: Re: [PATCH v2] x86: Remove compat vdso support
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
--
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/
Powered by blists - more mailing lists