This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Avoid deadlock in malloc on backtrace
- From: Rich Felker <dalias at libc dot org>
- To: Szabolcs Nagy <nsz at port70 dot net>
- Cc: Carlos O'Donell <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Fri, 27 Feb 2015 09:40:56 -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> <54EF9B9C dot 1080305 at redhat dot com> <20150227142009 dot GB16260 at port70 dot net>
On Fri, Feb 27, 2015 at 03:20:11PM +0100, Szabolcs Nagy wrote:
> * Carlos O'Donell <firstname.lastname@example.org> [2015-02-26 17:18:04 -0500]:
> > (1) Delaying the abort is bad for security.
> > Problem: The library should abort() immediately from a security perspective.
> > Solution: Don't delay, call abort() immediately.
> i think from security pov immediate crash (__builtin_trap) is the right solution
Absolutely. Even a simple function call (that goes via the PLT) or a
syscall (using a sysenter/syscall pointer in the TCB) is dangerous
when the process's memory space has already been trashed by an
> abort is complex (eg glibc tries to fflush stdio buffers)
Yes, and this is a bug. abort is required to be AS-safe, but there is
no way to do the flushing AS-safely. Attempting it in an AS-safe
manner with fallbacks may be possible, but the way it's done right now
is not safe, and such behavior does not seem useful anyway.
> > (2) Use a simpler backtrace.
> > - Use a backtrace that doesn't require dlopen, or malloc.
> > One doesn't exist, and would be hard to create, just look at the
> > work it took to get the unwinder to the level that it is in gcc
> > today.
> dlopen("libgcc_s.so") is bad
> when glibc and gcc are not the installed host tools it will use
> the wrong library because nobody would expect the libc to open
> shared objects of the compiler at runtime so that wont be in the
> library path: eg. the testrun.sh in glibc does not expect it
> > (5) Dynamically link with _Unwind_Backtrace to avoid dlopen's malloc.
> > - Link dynamically with libgcc_s.so in order to have immediate access
> > to the unwinder.
> as far as i'm concerned libgcc_s should not exist:
> such dependency between the c runtime and the compiler is bound to
> break things
> (i would be happy with a dummy backtrace)
I agree dlopen is bad but the glibc developers seem to have reasons
they don't want to change for not wanting to add -lgcc_s or -lgcc_eh
(static) related to bootstrapping. Perhaps an alternate would be to
include the unwind code directly in glibc?
BTW an equivalent issue affects pthread_cancel and causes it to crash
the program if libgcc_s.so cannot be loaded for any reason. I believe
there's an open bug report for this.