This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Avoid deadlock in malloc on backtrace
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Paul Eggert <eggert at cs dot ucla dot edu>, Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 26 Feb 2015 14:26:31 -0500
- Subject: Re: [PATCH] Avoid deadlock in malloc on backtrace
- Authentication-results: sourceware.org; auth=none
- References: <20150224100249 dot GA31871 at spoyarek dot pnq dot redhat dot com> <54EC52E6 dot 5010905 at redhat dot com> <20150224115158 dot GH23807 at spoyarek dot pnq dot redhat dot com> <54ECBA3D dot 90601 at cs dot ucla dot edu> <54ED94AC dot 3010502 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.