From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 6C13B385B83A for ; Mon, 29 Nov 2021 19:30:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6C13B385B83A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-546-3rM6o4H4PWOnOeonNb2pDg-1; Mon, 29 Nov 2021 14:30:52 -0500 X-MC-Unique: 3rM6o4H4PWOnOeonNb2pDg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 98CA1101F7A1; Mon, 29 Nov 2021 19:30:50 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.29]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7C92C608BA; Mon, 29 Nov 2021 19:30:47 +0000 (UTC) From: Florian Weimer To: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: libc-alpha@sourceware.org, Adhemerval Zanella , GCC Patches , Dmitry Vyukov , Marco Elver , Martin =?utf-8?Q?Li=C5=A1ka?= , Jakub Jelinek Subject: Re: [PATCH] elf: Add __libc_get_static_tls_bounds [BZ #16291] References: <20210925004227.1829014-1-maskray@google.com> <877df2i32a.fsf@oldenburg.str.redhat.com> <20210927175922.rofwqmouuymi7nlc@google.com> <20211006202305.j5lzyjsbf2n5pjm6@google.com> <20211015001339.3nrmohqvblck7gqa@google.com> Date: Mon, 29 Nov 2021 20:30:44 +0100 In-Reply-To: (=?utf-8?B?IkbEgW5nLXJ1w6wgU8OybmciJ3M=?= message of "Wed, 27 Oct 2021 22:16:39 -0700") Message-ID: <871r2yg3ob.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2021 19:30:57 -0000 * F=C4=81ng-ru=C3=AC S=C3=B2ng: > 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 =E2=80=9Cextern __thread int a[];=E2=80=9C 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