This is the mail archive of the
mailing list for the GCC project.
Re: [RFC][PR 67336][PING^6] Verify pointers during stack unwind
- From: Jeff Law <law at redhat dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: Jakub Jelinek <jakub at redhat dot com>, Yuri Gribov <tetra2005 at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Ian Lance Taylor <ian at airs dot com>, Andrew Pinski <pinskia at gmail dot com>
- Date: Thu, 3 Aug 2017 09:48:47 -0600
- Subject: Re: [RFC][PR 67336][PING^6] Verify pointers during stack unwind
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 48EA14A6F5
- References: <CAJOtW+4_FR+1zBiTvL_EBN7NGj-S9=7cR5Qsm560P7XsyLfFzA@mail.gmail.com> <email@example.com> <20170802184706.GO2123@tucnak> <firstname.lastname@example.org> <email@example.com>
On 08/02/2017 03:36 PM, Florian Weimer wrote:
> * Jeff Law:
>> Something like setup a signal handler when we first start unwinding that
>> flags the error and tear it down when we're done unwinding? Obviously
>> we can't do setup/tear down each time for each address. Anyway, just
>> thinking outloud here...
> Linux doesn't have per-thread signal handlers, so this doesn't work
Sigh. There's probably a multitude of reasons why this wouldn't work :-)
> If speed is not a concern, but reliability is, call fork (the system
> call, not glibc's wrapper which calls fork handlers) and do the work
> in a single-threaded copy of the process. There, you can set up
> signal handlers as you see fit, and the VM layout won't change
Speed is one of the concerns. Essentially we're pondering an efficient
mechanism to know if a given code address is valid so that we know if we
should even try to unwind through a particular stack frame.
One could probably claim that in the EH path a call to msync shouldn't
be a concern. I'm skeptical these days, but could be convinced that
> To harden unwinding against corrupted tables or table locations, we'd
> have to change ld.so to make all critical data read-only after loading
> and remove the unwinder caches (with more help from ld.so instead).
> It would make sense to move the unwinder implementation into ld.so.
> With proper hardening, corrupted stacks would not be able to cause
> crashes anymore, either.
Yea. I'm not sure if we're ready to suggest that kind of change yet,
but that may be the long term direction.