[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrWCXY-hwZh2U4QPp0YeeGuPXFUrUuCn7h-5H+TvdXEq5Q@mail.gmail.com>
Date: Tue, 11 Mar 2014 09:50:16 -0700
From: Andy Lutomirski <luto@...capital.net>
To: "H. Peter Anvin" <hpa@...ux.intel.com>
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
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.
--
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