Re: [PATCH] Avoid deadlock in malloc on backtrace

["Carlos O'Donell" <carlos at redhat dot com>]

On 02/25/2015 04:23 AM, Florian Weimer wrote:
> On 02/24/2015 06:51 PM, Paul Eggert wrote:
> 
>> But really, we shouldn't have to modify applications to work around this
>> problem, and the problem should be fixed in glibc.  'backtrace'
>> shouldn't require 'malloc' to work, as we want 'backtrace' to get a
>> backtrace as reliably as possible even when part of memory is corrupted.
> 
> That's simply not possible with an in-process backtrace.  As I already
> said, I think it is a bad idea to continue running after detecting a
> security violation.  The idea that it's somehow possible to recover from
> stack or heap corruption is fundamentally flawed.

You have one of two cases:

* You are finishing printing an error message and will abort(). The
  process is on it's way to being shut down and it is very hard to stop
  it from doing so without changing read-only code.

* You have called mcheck to setup a handler, or have a SIGABRT handler,
  and will longjmp back to a point in the program execution where you
  will reinitialize the entire runtime or as much as you can.

The latter is a valid and presently supported mode of operation. As a
conservative project we have allowed such behaviours for developers
that are writing robust code. Those developers make a choice about the
safety and trade-off in the face of errors, not all of which are
security issues. Consider rad-hardened systems, robust systems with
failing memory, etc. etc.

Cheers,
Carlos.