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: Andrew Hunter <ahh at google dot com>
- To: Kostya Serebryany <kcc at google dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>, Roland McGrath <roland at hack dot frob dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, address-sanitizer at googlegroups dot com
- Date: Thu, 23 Jan 2014 13:59:08 -0800
- Subject: Re: glibc 2.19 - asyn-signal safe TLS and ASan.
- Authentication-results: sourceware.org; auth=none
- References: <52D0BCED dot 3000109 at redhat dot com> <52DDBF0E dot 8010501 at redhat dot com> <CAN=P9piS3Xczq2AKrzh4rsK9JxiHtJXawcQs9_+xsYXxrbLQWQ at mail dot gmail dot com>
FYI -- you could easily do the same thing with calls to
signal_safe_memalign from libc as a stopgap. (Well, we'd need to
export the symbols from libc, like I wanted to in the first place.)
On Thu, Jan 23, 2014 at 7:35 AM, Kostya Serebryany <kcc@google.com> wrote:
> [plain text now]
>
> Thanks again for reaching us.
> The new TLS implementation *is* a problem for us as it turns out.
> At least for LeakSanitizer (lsan) it will cause a false positive leak report.
> Admittedly, the current lsan's implementation has an ugly hack around TLS,
> which was the major reason for filing
> https://sourceware.org/bugzilla/show_bug.cgi?id=16291
> In short, we treat __libc_memalign called from elf/dl-tls.c in a special way
> which allows us to include the dynamic TLS into the leak detector's
> memory root set.
> More:
> http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/lsan/lsan_common_linux.cc?view=diff&r1=199899&r2=199900&pathrev=199900
>
> I suggest we continue the discussion in
> https://sourceware.org/bugzilla/show_bug.cgi?id=16291
> unless you prefer otherwise. Let me post more details there.
>
> I also suspect that the new TLS implementation may cause us trouble in
> MemorySanitizer,
> but I haven't tried to verify that yet.
>
>
> --kcc
>
>
>
> On Tue, Jan 21, 2014 at 4:27 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>> Konstantin,
>>
>> I've forwarded your response to libc-alpha which I assume rejected
>> your multi-part plain/html email.
>>
>> I've also corrected the small mistake that the next release is 2.19
>> not 2.20. Sorry.
>>
>> +address-sanitizer@googlegroups.com
>>
>> Hi Carlos,
>>
>> Thanks for the heads up!
>> I don't expect any impact on ASan from this change.
>> We'd still test ASan with the new glibc to make sure.
>>
>> --kcc
>>
>>
>>
>> On Sat, Jan 11, 2014 at 7:39 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> Hello Konstantin!,
>>
>> You're getting this email because you're the only ASan expert I know,
>> and I was at your talk at LFCS2013 ;-)
>>
>> We have a problem and we'd like your input if you have time.
>>
>> The GNU C Library version 2.20 (coming out at the end of the month)
>> plans to stop using malloc for TLS allocations. The reason for this
>> is that malloc is async-signal unsafe, and TLS accessed in signal
>> handlers may need to allocate storage at the time of access. This
>> is particularly true of signal handlers provided by dlopened shared
>> libraries. There is no way to interpose yourself here because the
>> non-malloc signal-safe allocator being used is internal to glibc.
>>
>> What kind of impact do you see this having on ASan?
>>
>> Do you see any way we can mitigate this impact?
>>
>> Cheers,
>> Carlos.
>>