Re: [PATCH][_GLIBCXX_DEBUG] libbacktrace integration

[Jonathan Wakely <jwakely@redhat.com>]

On 04/05/21 08:03 +0200, François Dumont wrote:
>On 03/05/21 11:06 pm, Jonathan Wakely wrote:
>>On 03/05/21 22:17 +0200, François Dumont via Libstdc++ wrote:
>>>Is it too early to consider this patch ? Or just lack of time ?
>>
>>I haven't had time to review it yet, but my general feeling hasn't
>>changed. I still don't like the idea of executing additional code
>>after undefined behaviour is detected. I've been convinced by glibc
>>folk that every bit of code run when the program state is corrupt
>>increases the risk that it can be exploited by an attacker.
>>
>>
>>
>Ok, I must have miss (or forgot) this feedback.

See https://gcc.gnu.org/pipermail/libstdc++/2018-December/048061.html

>Well, isn't it the current situation of the whole _GLIBCXX_DEBUG mode ?

Yes, but adding more code makes it worse.

>For me _GLIBCXX_DEBUG mode purpose is to detect UB situation and to 
>assert _before_ any UB code is run.

Yes, it stops running the user code, but then runs its own code to
format the message to show to the user. The more code that runs when
the program is in an inconsistent/undefined state, the more likely it
is that some of that code can be exploited to do something bad.

>Moreover it is optional. This is a feature to use when _GLIBCXX_DEBUG 
>is telling you that you have a problem in your code but you just 
>cannot find where it is called.

Which you can do with a debugger. When debug mode calls abort() it
will stop the program in a debugger, or produce a core file that can
be examined in a debugger.

The stacktrace is a convenience, not providing anything that couldn't
be done already.

Anyway, I'll review the patch...