On Mon, Nov 29, 2021 at 11:30 AM Florian Weimer <fwei...@redhat.com> wrote: > > * 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?
Perhaps add HWAddressSanitizer along with Address Sanitizer and Memory Sanitizer along with Thread Sanitizer. Then I think the list is complete. > 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. Unfortunate no, not reliably. Currently _dl_get_tls_static_info (https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp#L207) is used. It has the size information but not the start address, so the sanitizer runtime is doing very ugly/error-prone probing of the start address by reading the thread pointer and hard coding the `struct pthread` size for various glibc versions. Every time `struct pthreads` increases in glibc, sanitizer runtime has to adapt. __libc_get_static_tls_bounds if supported by glibc, can replace _dl_get_tls_static_info and the existing glibc specific GetTls hacks, and provide a bit more compatibility when glibc struct pthreads increases. > (Cc:ing a few people from a recent GCC thread.) > > Thanks, > Florian > -- 宋方睿
