Re: [Libunwind-devel] Bug fixes in libunwind git = make another "release"?

[Konstantin Belousov]

On Mon, Mar 21, 2011 at 02:09:19PM -0700, Arun Sharma wrote:
> On Mon, Mar 21, 2011 at 10:46 AM, Lassi Tuura <address@hidden> wrote:
...
> >
> > Another issue continuing to bite us from time to time is the
> > deadlock in dl_iterate_phdr() if you attempt to get a stack trace right
> > in the middle of dynamic linker holding - or even taking - that lock.
> > Previously it was suggested app might trap into _dl_debug_state() to
> > grab the list then tell libunwind to use the list not dl_iterate_phdr().
> > I am willing to see if this can fly, but thoughts would be welcome.
FreeBSD offers signal-safe dl_iterate_phdr(), basically because
the rtld masks signal as part of the lock entry procedure. The FreeBSD
port is fine with the current use of dl_iterate_phdr(), so please at least
keep the current code where it is safe.

> 
> I wish we could convince glibc developers to implement what we need (a
> lock free implementation of a dl_iterate_phdr() like interface).
> 
> >
> > We build our libunwind with --disable-block-signals, which turns off 
> > sigprocmask() calls with mutexes as they cost a bit and aren't needed in 
> > our case. How would we recommend a distro build libunwind?
> 
> My guess is that a higher level API such as src/mi/backtrace.c is
> sufficient for most users. As long as we ensure signal safety in such
> a higher level API, we could make --disable-block-signals the default
> (with some man page, documentation updates of course).
> 
> >
> > Should we advise distros that libunwind is dangerous in security sensitive 
> > code / user apps unless the entire userland has been compiled with GCC 
> > 4.5+? The invalid unwind info is a large attack vector... Earlier we 
> > enabled full address validation at least on x86-64 - but the fast trace 
> > code runs with validation off. Even with validation I am somewhat concerned 
> > this gets used to attack apps, bring down servers, or such.
> 
> The security situation should improve If we stop unwinding when there
> is missing dwarf information and identify signal frames only by
> augmentation attribute (essentially turning off frame chain based
> unwinding). Do you have any data on what percentage of the frames are
> lost if we do this on a gcc-4.5+ setup?

Again, talking from the FreeBSD port POV, we need the signal trampoline
detection, and will need it in foreseeable future. Currently, trampolines
are mapped (or copied) by kernel as a bit of naked code, without wrapping
them into vdso.

pgpmVX3f5YZ2L.pgp
Description: PGP signature