This is the mail archive of the
mailing list for the GCC project.
Re: [musl] RFC: adding Linux vsyscall-disable and similar backwards-incompatibility flags to ELF headers?
- From: Rich Felker <dalias at libc dot org>
- To: Andy Lutomirski <luto at amacapital dot net>
- Cc: Kees Cook <keescook at chromium dot org>, "linux-kernel at vger dot kernel dot org" <linux-kernel at vger dot kernel dot org>, libc-alpha <libc-alpha at sourceware dot org>, "musl at lists dot openwall dot com" <musl at lists dot openwall dot com>, gcc at gcc dot gnu dot org, Binutils <binutils at sourceware dot org>
- Date: Wed, 2 Sep 2015 00:55:23 -0400
- Subject: Re: [musl] 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> <20150902025440 dot GG17773 at brightrain dot aerifal dot cx> <CALCETrXDQ5jE5d_2ait_KP+JQhGExOW=MPPcGCzrGcYS7eMPvQ at mail dot gmail dot com> <20150902041815 dot GH17773 at brightrain dot aerifal dot cx> <CALCETrUeyF3TzXsrgYhdEz4BTSp4FUh_nh=bssixx1yuNGA57Q at mail dot gmail dot com>
On Tue, Sep 01, 2015 at 09:32:22PM -0700, Andy Lutomirski wrote:
> On Tue, Sep 1, 2015 at 9:18 PM, Rich Felker <email@example.com> wrote:
> > On Tue, Sep 01, 2015 at 08:39:27PM -0700, Andy Lutomirski wrote:
> >> On Tue, Sep 1, 2015 at 7:54 PM, Rich Felker <firstname.lastname@example.org> wrote:
> >> > On Tue, Sep 01, 2015 at 05:51:44PM -0700, Andy Lutomirski 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.
> >> >
> >> > Is there a practical problem you're trying to solve? My understanding
> >> > is that the vsyscall nonsense is fully emulated now and that the ways
> >> > it could be used as an attack vector have been mitigated.
> >> They've been mostly mitigated, but not fully. See:
> >> http://googleprojectzero.blogspot.com/2015/08/three-bypasses-and-fix-for-one-of.html
> > That looks like it would be mitigated by not having any mapping there
> > at all and having the kernel just catch the page fault and emulate
> > rather than filling it with trapping opcodes for the kernel to catch.
> Oddly, that causes a compatibility problem. There's a program called
> pin that does dynamic instrumentation and actually expects to be able
> to read the targets of calls. The way that Linux handles this now is
Um, do people seriously need to do this dynamic instrumentation on
ancient obsolete binaries? This sounds to me like confused