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

[Arun Sharma]

On Mon, Mar 21, 2011 at 10:46 AM, Lassi Tuura <address@hidden> wrote:

> One of the things that continues to affect us is the introduction of 
> mincore() call vs. msync() for address validation: mincore() gives an 
> incorrect answer for MAP_PRIVATE mappings for linux kernels prior to 2.6.21. 
> Can we make libunwind auto-detect whether mincore() works and fall back on 
> msync(), or at least integrate the patch to make it configure-time option?

I'll add a configure time check for this unless someone else beats me to it.

>
> 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.

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?

 -Arun