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

[Lassi Tuura]

Hi,

> Yes - it's been a while since the last release. We should try and get
> something out this summer for the distros.
> 
> After 0.99 comes 1.0! I'm interested in hearing feedback about issues,
> irritants, bugs people want to get fixed before the next release.
> 
> Also, if there are features you'd like to vote for (or contribute!),
> please speak up in the next few days. Fast unwinding + slow fallback
> on x86 seems to be a popular feature. Anything else?

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?

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.

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?

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.

Apart for finishing the work on the fast trace, for which I have been working 
recently and hope to submit patches later this week, the msync is quite 
important to us. The deadlock is awkward but we can live with it. The configure 
option doesn't really matter to us as we build our own libunwind anyway, but it 
may matter more one day.

Regards,
Lassi