public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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


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