mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Ian Lance Taylor <iant@google.com>
Cc: "musl@lists.openwall.com" <musl@lists.openwall.com>,
	gcc@gcc.gnu.org, Kees Cook <keescook@chromium.org>,
	libc-alpha <libc-alpha@sourceware.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Binutils <binutils@sourceware.org>
Subject: Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
Date: Tue, 1 Sep 2015 19:23:38 -0700	[thread overview]
Message-ID: <CALCETrVftHaPzFsVOC7qLV0kup4R0urSF=nVx27W2AcOcufsBw@mail.gmail.com> (raw)
In-Reply-To: <CAKOQZ8xS5-BmoX2QeONbmJuSMZvL1fLoxkgyoVy5mpFWziZ3Dg@mail.gmail.com>

On Sep 1, 2015 6:12 PM, "Ian Lance Taylor" <iant@google.com> wrote:
>
> On Tue, Sep 1, 2015 at 5:51 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> >
> > Linux has a handful of weird features that are only supported for
> > backwards compatibility.  The big one is the x86_64 vsyscall page, but
> > uselib probably belongs on the list, too, and we might end up with
> > more at some point.
> >
> > I'd like to add a way that new programs can turn these features off.
> > In particular, I want the vsyscall page to be completely gone from the
> > perspective of any new enough program.  This is straightforward if we
> > add a system call to ask for the vsyscall page to be disabled, but I'm
> > wondering if we can come up with a non-syscall way to do it.
> >
> > I think that the ideal behavior would be that anything linked against
> > a sufficiently new libc would be detected, but I don't see a good way
> > to do that using existing toolchain features.
> >
> > Ideas?  We could add a new phdr for this, but then we'd need to play
> > linker script games, and I'm not sure that could be done in a clean,
> > extensible way.
>
> What sets up the vsyscall page, and what information does it have
> before doing so?
>
> I'm guessing it's the kernel that sets it up, and that all it can see
> at that point is the program headers.

Currently it's global and nothing thinks about it per-process at all.
The kernel can do whatever it likes going forward, subject to
backwards compatibility.  Doing something at ELF load time is probably
the right approach.

>
> We could pass information using an appropriate note section.  My
> recollection is that the linkers will turn an SHF_ALLOC note section
> into a PT_NOTE program header.

Oh, interesting.  I'll check that.  Glibc and competitors could add
notes to their statically-linked bits.

The unpleasant case is a new dynamic binary linked against an old
libc, but that might be irrelevant in practice.  After all, I think
that a lot of libc competitors never supported the vsyscall page at
all, and even glibc isn't really backwards compatible that way.

We could also require that both the binary and interpreter have the
note, which would more or less solve the backwards compatibility
issue.

--Andy

  reply	other threads:[~2015-09-02  2:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-02  0:51 Andy Lutomirski
2015-09-02  1:12 ` Ian Lance Taylor
2015-09-02  2:23   ` Andy Lutomirski [this message]
2015-09-02  1:53 ` Brian Gerst
2015-09-02  2:21   ` Andy Lutomirski
2015-09-02 13:57     ` Brian Gerst
2015-09-02 14:08       ` Andy Lutomirski
2015-09-02  2:54 ` [musl] " Rich Felker
2015-09-02  3:39   ` Andy Lutomirski
2015-09-02  4:18     ` Rich Felker
2015-09-02  4:32       ` Andy Lutomirski
2015-09-02  4:55         ` Rich Felker
2015-09-02  5:03           ` Andy Lutomirski
2015-09-02  5:22             ` Rich Felker
2015-09-02 12:48         ` Austin S Hemmelgarn

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='CALCETrVftHaPzFsVOC7qLV0kup4R0urSF=nVx27W2AcOcufsBw@mail.gmail.com' \
    --to=luto@amacapital.net \
    --cc=binutils@sourceware.org \
    --cc=gcc@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=keescook@chromium.org \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=musl@lists.openwall.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).