This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: glibc 2.19 - asyn-signal safe TLS and ASan.


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();).

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]