From: "H. Peter Anvin" <hpa@linux.intel.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Stefani Seibold <stefani@seibold.net>,
the arch/x86 maintainers <x86@kernel.org>,
Dave Jones <davej@redhat.com>,
Martin Runge <Martin.Runge@rohde-schwarz.com>,
Andreas Brief <Andreas.Brief@rohde-schwarz.com>
Subject: Re: [PATCH v2] x86: Remove compat vdso support
Date: Tue, 11 Mar 2014 09:52:39 -0700 [thread overview]
Message-ID: <531F3F57.8090105@linux.intel.com> (raw)
In-Reply-To: <CALCETrWCXY-hwZh2U4QPp0YeeGuPXFUrUuCn7h-5H+TvdXEq5Q@mail.gmail.com>
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
next prev parent reply other threads:[~2014-03-11 16:54 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-11 1:03 [PATCH v2] x86: Remove compat vdso support Andy Lutomirski
2014-03-11 1:39 ` Linus Torvalds
2014-03-11 2:37 ` Andy Lutomirski
2014-03-11 3:09 ` Linus Torvalds
2014-03-11 4:10 ` Andy Lutomirski
2014-03-11 8:37 ` Ingo Molnar
2014-03-11 9:36 ` Linus Torvalds
2014-03-11 14:53 ` Andy Lutomirski
2014-03-11 15:30 ` Linus Torvalds
2014-03-11 16:14 ` H. Peter Anvin
2014-03-11 16:30 ` Linus Torvalds
2014-03-11 16:42 ` Andy Lutomirski
2014-03-11 16:42 ` H. Peter Anvin
2014-03-11 16:45 ` Andy Lutomirski
2014-03-11 16:50 ` Andy Lutomirski
2014-03-11 16:52 ` H. Peter Anvin [this message]
2014-03-11 17:09 ` Linus Torvalds
2014-03-11 17:14 ` H. Peter Anvin
2014-03-11 17:16 ` Andy Lutomirski
2014-03-12 8:30 ` Stefani Seibold
2014-03-12 14:41 ` Linus Torvalds
2014-03-12 15:46 ` Linus Torvalds
2014-03-12 16:04 ` Linus Torvalds
2014-03-12 16:18 ` Brian Gerst
2014-03-12 16:18 ` Andy Lutomirski
2014-03-12 19:41 ` Linus Torvalds
2014-03-12 20:52 ` Andy Lutomirski
2014-03-12 21:37 ` H. Peter Anvin
2014-03-12 21:45 ` Andy Lutomirski
2014-03-12 21:46 ` Linus Torvalds
2014-03-12 21:49 ` Andy Lutomirski
2014-03-12 23:06 ` H. Peter Anvin
2014-03-12 23:43 ` Andy Lutomirski
2014-03-12 23:46 ` H. Peter Anvin
2014-03-13 16:23 ` Thomas Gleixner
2014-03-12 13:55 ` One Thousand Gnomes
2014-03-13 7:08 ` George Spelvin
2014-03-11 17:03 ` H. Peter Anvin
2014-03-11 17:07 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=531F3F57.8090105@linux.intel.com \
--to=hpa@linux.intel.com \
--cc=Andreas.Brief@rohde-schwarz.com \
--cc=Martin.Runge@rohde-schwarz.com \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=stefani@seibold.net \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.