On Mon, Mar 21, 2011 at 02:09:19PM -0700, Arun Sharma wrote: > On Mon, Mar 21, 2011 at 10:46 AM, Lassi Tuura <[email protected]> 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.
pgp2BMGgWavj8.pgp
Description: PGP signature
_______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
