[RFC][PR 67336][PING^6] Verify pointers during stack unwind

[H.J. Lu]

On Wed, Aug 2, 2017 at 1:39 PM, Yury Gribov <tetra2005.patches@gmail.com> wrote:
> On 02.08.2017 20:02, Jeff Law wrote:
>>
>> On 08/02/2017 12:47 PM, Jakub Jelinek wrote:
>>>
>>> On Wed, Aug 02, 2017 at 12:38:13PM -0600, Jeff Law wrote:
>>>>
>>>> On 07/17/2017 01:23 AM, Yuri Gribov wrote:
>>>>>
>>>>> I've rebased the previous patch to trunk per Andrew's suggestion.
>>>>> Original patch description/motivation/questions are in
>>>>> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01869.html
>>>>
>>>> Is his stuff used for exception handling?  If so, doesn't that make the
>>>> performance a significant concern (ie that msync call?)
>>>
>>>
>>> For the performance issue, I wonder if it wouldn't be better to just
>>> compile the unwinder twice, basically include everything needed for the
>>> verification backtrace in a single *.c file with special defines, and
>>> not export anything from that *.o file except the single entrypoint.
>>> That would also handle the ABI problems.
>>
>> Yea.
>>
>> Given that the vast majority of the time the addresses are valid, I
>> wonder if we could take advantage of that property to keep the overhead
>> lower in the most common cases.
>>
>>> For the concurrent calls of other threads unmapping stacks of running
>>> threads (that is where most of the verification goes against), I'm afraid
>>> that is simply non-solveable, even if you don't cache anything, it will
>>> still be racy.
>>
>> Absolutely -- I think solving this stuff 100% reliably without races
>> isn't possible.  I think the question is can we make this significantly
>> better.
>
>
> All,
>
> First of all, thanks for the feedback.  This is indeed not a 100% robust
> solution, just something to allow tools like Asan to produce more sane
> backtraces on crash (currently when stack is corrupted they would crash in
> the unwinder without printing at least partial backtrace).
>

FWIW, glibc 2.26 is changed to abort as soon as possible when stack is
corrupted:

https://sourceware.org/bugzilla/show_bug.cgi?id=21752
https://sourceware.org/bugzilla/show_bug.cgi?id=12189

There is very little point to unwind stack when stack is corrupted.


-- 
H.J.