Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 26 May 2021 20:09:27 -0700
From: Fangrui Song <>
To: Florian Weimer <>
Cc: Kostya Serebryany <>,
	Evgenii Stepanov <>, enh <>,
Subject: Re: Thread properties API

On 2021-05-23, Fangrui Song wrote:
>Thanks for proposing this.
>On 2021-05-21, Florian Weimer wrote:
>>In glibc, we have a historic gap when it comes to access to per-thread
>>data that may contain application data.  Such functionality is required
>>to support memory leak detectors and conservative garbage collectors
>>that need to discover pointer values in TLS data.  The sanitizers
>>currently hard-code glibc implementation details (that are not really
>>unchanging in practice), and we want to switch to a defined interface
>Currently msan and tsan intercept __tls_get_addr so that newly allocated TLS
>can be tracked and immediately acted upon. See my attached notes for
>(Note: aarch64 uses TLSDESC by default and there is no interposable symbol.)
>Is there an observer API for the new allocated TLS area?
>(msan's hook is async-signal-safe (even though lazy TLS allocation
>isn't). It does very simple unpoison operation.)
"Detect dynamic TLS allocations for glibc>=2.19"
provides more context on the dynamic TLS detection needs.
It is motivated by a recent msan false positive due to TLS
inconvenience ;-)

In the near term (a few years?) sanitizers may need to work around the
issue, but hope the API can make the future world more robust:)

>[I am attaching my notes about sanitizer runtime's usage of TLS
>boundaries. Hope that can be useful.]

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.