This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: glibc 2.19 - asyn-signal safe TLS and ASan.
- From: Kostya Serebryany <kcc at google dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, OndÅej BÃlka <neleai at seznam dot cz>, "Joseph S. Myers" <joseph at codesourcery dot com>, Andrew Hunter <ahh at google dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, address-sanitizer at googlegroups dot com
- Date: Fri, 31 Jan 2014 09:10:38 +0400
- Subject: Re: glibc 2.19 - asyn-signal safe TLS and ASan.
- Authentication-results: sourceware.org; auth=none
- References: <20140125030232 dot GA14213 at domone dot podge> <CAN=P9pgiMRxxYK16ZaVje1AQbC+fQ=QUDhsdww5-8RWaiJswoA at mail dot gmail dot com> <CALoOobMdh7wOHPPB6vTTLb0wXeO-yGA75MvHohrqGPAY-CcC2g at mail dot gmail dot com> <CAN=P9pjAW6bMip+hsE6mDUA2MFfdC7fNCvrgNyhG2GRQGJJNCw at mail dot gmail dot com> <CAN=P9pj+EVcrUwxa+70eEVY-_sqaU1d6s8HjsP4BkY8N+G-JVg at mail dot gmail dot com> <52E9E1E7 dot 3090505 at redhat dot com> <CAN=P9pgyfA6hTC2LcQEpALo62g8+wN0Ne-eJsMnZ7iR1m9rzOg at mail dot gmail dot com> <52E9E7CF dot 9060706 at redhat dot com> <20140130165445 dot GU24286 at brightrain dot aerifal dot cx> <CAN=P9piLnJh=RM+B61jN2-3t6RM5dpsfFDy-9cirM0yjbRgdaQ at mail dot gmail dot com> <20140130175028 dot GW24286 at brightrain dot aerifal dot cx>
On Thu, Jan 30, 2014 at 9:50 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Thu, Jan 30, 2014 at 09:38:59PM +0400, Kostya Serebryany wrote:
>> On Thu, Jan 30, 2014 at 8:54 PM, Rich Felker <dalias@aerifal.cx> wrote:
>> > On Thu, Jan 30, 2014 at 12:49:03AM -0500, Carlos O'Donell wrote:
>> >> On 01/30/2014 12:33 AM, Kostya Serebryany wrote:
>> >> > On Thu, Jan 30, 2014 at 9:23 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> >> >>
>> >> >> On 01/29/2014 04:48 AM, Kostya Serebryany wrote:
>> >> >>> [text only]
>> >> >>>
>> >> >>>> Indeed so, thanks!
>> >> >>>> So, exporting __signal_safe_memalign&co will allow us to extend the
>> >> >>>> existing hack to 2.19.
>> >> >>>> If this simple change can not be done for 2.19, can *anything* be done at all?
>> >> >>>> (Long term we'd still prefer something less hackish)
>> >> >>>
>> >> >>> FTR, I've implemented an even-uglier-then-before hack that deals with
>> >> >>> dynamic TLS in both <=2.18 and 2.19.
>> >> >>> So, we will survive the 2.19 release.
>> >> >>> But I would appreciate if we can resolve
>> >> >>> https://sourceware.org/bugzilla/show_bug.cgi?id=16291
>> >> >>> before the next one (2.20).
>> >> >>
>> >> >> Can you please describe the hack?
>> >> >
>> >> > intercept __tls_get_addr and __libc_memalign.
>> >> > if __libc_memalign is called while we are inside __tls_get_addr, we
>> >> > know we are in <= 2.18 mode and we know what to do.
>> >
>> > Or a signal handler happened to interrupt __tls_get_addr and something
>> > from the signal handler caused __libc_memalign to get called. Is this
>> > case handled?
>>
>> Is __libc_memalign AS-safe? I guess not.
>> AddressSanitizer's implementation is certainly not.
>> So, if __libc_memalign is called in a signal handler it is a problem by itself.
>> That's what forced the the change in 2.19 in the first place.
>
> It's legal to call anything (even non AS-safe functions) from a signal
> handler if the signal handler did not interrupt a non-AS-safe
> function. This is easy to guarantee if the only threads where the
> signal is unblocked are only using AS-safe functions (a trivial
> example would be a thread doing for (;;) pause();).
Well, in <=2.18 this means that we can not call malloc in signal
handler while using tls, so for <=2.18 the hack is safe.
Then, there is a check in my hack that the result of the last
__libc_memalign is is the same as the current result
of __tls_get_addr (minus offset), so if we are in 2.19 mode and
__libc_memalign is never called from __tls_get_addr
we are still safe even if __libc_memalign is called from a signal
handler. (I think...)
--kcc
>
> Rich