This is the mail archive of the
mailing list for the binutils project.
Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
- From: Andy Lutomirski <luto at amacapital dot net>
- To: Brian Gerst <brgerst at gmail dot com>
- Cc: "musl at lists dot openwall dot com" <musl at lists dot openwall dot com>, Kees Cook <keescook at chromium dot org>, gcc at gcc dot gnu dot org, libc-alpha <libc-alpha at sourceware dot org>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>, Binutils <binutils at sourceware dot org>
- Date: Tue, 1 Sep 2015 19:21:01 -0700
- Subject: Re: RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
- Authentication-results: sourceware.org; auth=none
- References: <CALCETrUzU5UVe_2eWuMCOgHTs=5mnor5m0RO0STTi3K5FzdNvQ at mail dot gmail dot com> <CAMzpN2gQq7TbmjgHYut53gNTLCtVQ197akKZ69ZoM1BHHMo8cQ at mail dot gmail dot com>
On Sep 1, 2015 6:53 PM, "Brian Gerst" <firstname.lastname@example.org> wrote:
> On Tue, Sep 1, 2015 at 8:51 PM, Andy Lutomirski <email@example.com> wrote:
> > Hi all-
> > 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.
> The vsyscall page is mapped in the fixmap region, which is shared
> between all processes. You can't turn it off for an individual
We already emulate all attempts to execute it, and that's trivial to
turn of per process. Project Zero pointed out that read access is a
problem, too, but we can flip the U/S bit in the pgd once we evict
pvclock from the fixmap.
And we definitely need to evict pvclock from the fixmap regardless.