From: Florian Weimer <fweimer@redhat.com>
To: "Fāng-ruì Sòng" <maskray@google.com>
Cc: libc-alpha@sourceware.org,
"Adhemerval Zanella" <adhemerval.zanella@linaro.org>,
"GCC Patches" <gcc-patches@gcc.gnu.org>,
"Dmitry Vyukov" <dvyukov@google.com>,
"Marco Elver" <elver@google.com>, "Martin Liška" <mliska@suse.cz>,
"Jakub Jelinek" <jakub@redhat.com>
Subject: Re: [PATCH] elf: Add __libc_get_static_tls_bounds [BZ #16291]
Date: Mon, 29 Nov 2021 20:30:44 +0100 [thread overview]
Message-ID: <871r2yg3ob.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAFP8O3KFOz8azOdZo7gecUE+5xRj5iPRoo8+L7B56Sf5NB=iqQ@mail.gmail.com> (=?utf-8?B?IkbEgW5nLXJ1w6wgU8OybmciJ3M=?= message of "Wed, 27 Oct 2021 22:16:39 -0700")
* 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
next prev parent reply other threads:[~2021-11-29 19:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-25 0:42 Fangrui Song
2021-09-27 13:02 ` Florian Weimer
2021-09-27 17:59 ` Fangrui Song
2021-10-06 20:23 ` Fangrui Song
2021-10-15 0:13 ` Fangrui Song
2021-10-19 19:37 ` Fāng-ruì Sòng
2021-10-28 5:16 ` Fāng-ruì Sòng
2021-11-29 19:30 ` Florian Weimer [this message]
2021-12-21 2:55 ` Fāng-ruì Sòng
2021-12-21 6:08 ` Florian Weimer
2021-09-27 17:38 ` Joseph Myers
2021-09-27 17:47 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871r2yg3ob.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=adhemerval.zanella@linaro.org \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=maskray@google.com \
--cc=mliska@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).