[PATCH] elf: Add __libc_get_static_tls_bounds [BZ #16291]
Florian Weimer
fweimer@redhat.com
Mon Nov 29 19:30:44 GMT 2021
* Fāng-ruì Sòng:
> PING^3
I think the core issue with this patch is like this:
* I do not want to commit glibc to a public API that disallows future
changes to the way we allocate static TLS. While static TLS objects
cannot move in memory, the extent of the static TLS area (minimum and
maximum address) is not fixed by ABI necessities.
* Joseph does not want to add a GLIBC_PRIVATE ABI that is exclusively
used externally.
I have tried repeatly to wrap my head around how the sanitizers use the
static TLS boundary information. Based on what I can tell, there are
several applications:
1. Thead Sanitizer needs to know application-accessible thread-specific
memory that is carried via the glibc thread (stack) cache from one
thread to another one, seemingly without synchronization. Since the
synchronization happens internally within glibc, without that extra
knowledge, Thread Sanitizer would report a false positive. This
covers only data to which the application has direct access, internal
access by glibc does not count because it is not going to be
instrumented.
2. Address Sanitizer needs TLS boundary information for bounds checking.
Again this only applies to accesses that can be instrumented, so only
objects whose addresses leak to application code count. (Maybe this
is a fringe use case, though: it seems to apply only to “extern
__thread int a[];“ and similar declarations, where the declared type
is not enough.)
3. Leak Sanitizer needs to find all per-thread pointers pointing into
the malloc heap, within memory not itself allocated by malloc. This
includes the DTV, pthread_getspecific metadata, and perhaps also user
data set by pthread_getspecific, and of course static TLS variables.
This goes someone beyond what people would usually consider static
TLS: the DTV and struct pthread are not really part of static TLS as
such. And struct pthread has several members that contain malloc'ed
pointers.
Is this a complete list of uses?
I *think* you can get what you need via existing GLIBC_PRIVATE
interfaces. But in order to describe how to caox the data out of glibc,
I need to know what you need.
(Cc:ing a few people from a recent GCC thread.)
Thanks,
Florian
More information about the Gcc-patches
mailing list