This is the mail archive of the
gcc-patches@gcc.gnu.org
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 11:19:56 -0600
- Subject: Re: [RFC][PR 67336][PING^6] Verify pointers during stack unwind
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx07.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 7438AC04B32C
- References: <CAJOtW+4_FR+1zBiTvL_EBN7NGj-S9=7cR5Qsm560P7XsyLfFzA@mail.gmail.com> <96fda4ab-0c92-96ea-1993-5c235b1a8b03@redhat.com> <20170802184706.GO2123@tucnak> <0145b4fc-c15e-be6d-164d-d3a284e82079@redhat.com> <87lgn17itj.fsf@mid.deneb.enyo.de> <81c40c26-0cb8-c02c-3af4-a5015bc63295@redhat.com> <87r2wsy46z.fsf@mid.deneb.enyo.de>
On 08/03/2017 11:03 AM, Florian Weimer wrote:
> * Jeff Law:
>
>>> 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
>>> unexpectedly.
>
>> Speed is one of the concerns.
>
> I thought this was debugging-only, optional unwinder behavior.
My understanding was this was in the EH path as well. If it's outside
the EH path, then I don't care about the cost of msync and the like :-)
>
>> 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.
>
> Efficient code address validation is possible using data structures
> maintained by ld.so. If those data structures are mostly read-only,
> they cannot be corrupted, so pointers and offsets in them don't have
> to be validated before derefencing them.
Understood.
>
> But the main problem is the frame pointer chain, and the current lack
> of registration for stacks. The program can just malloc some area,
> switch the SP, and start running from there. Some libraries do
> exactly that. And without knowledge of the bottom address of the
> stack, it is impossible to verify that the frame pointer chain goes
> somewhere off the stack.
Yea.
>
>> 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
>> it's tolerable.
>
> Quite a few applications are sensitive to EH performance. The current
> freshness check for the cache is very inefficient, which is a
> significant problem for some users. If we can push out the flag check
> the top level (essentially compiling the unwinder twice, with and
> without checking), I don't think this would cause significant
> additional performance issues.
Yea. I went back and reviewed the internal BZ. It's actually just the
print-a-backtrace thing rather than EH unwinding. SO yea, if the
print-a-backtrace path and EH path both use bits, we could just compile
them twice, once with checking once without respectively.
Jeff