From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) by sourceware.org (Postfix) with ESMTPS id 8C5BD3858C60 for ; Tue, 21 Dec 2021 02:55:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8C5BD3858C60 Received: by mail-yb1-xb36.google.com with SMTP id 131so34468933ybc.7 for ; Mon, 20 Dec 2021 18:55:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=8AA/E8SpkGnhkkuPcEif2xVftdhC11r3No3de5YUbQ0=; b=OufzFjym/+ZCE0BtJS5khV57dLLsC8RnIhbkRcPncElTECYC2xHM+iVKTsLvXE1OOH R2dV59hkIeh5fc+KMH3rbpo60wbVYMDtKZjjJh/cl5lxdM7OHl0im9vvvZVOwmWfgWAC hDsCR2QLf+jv25Gntr15DW1XzPvyFFcrnoJFQ1iSO8rBKpHMvvoRNNXSqKlFomHxzFsI Dsl7VpdYZiOAHwttmLffZMZjp44DXpl5gayQ5GBfKQB6b+kPVLph1xdGMVic/pzZfMUE LBHs5gwkyKf8mgEVG9uYEukhit8bQBw8FLNHeDL6H089q3kmqcoVadgujFSBl3bjYiKa w7rg== X-Gm-Message-State: AOAM532c3MH4OZpj+Dc8VJ0ueyyvISYixB5qzd2t8uoEt1b6Uf7nbChd 0PDvCDdXJKLV02UCz+y1H3sAZp7USxiCKEk4X7wpTw== X-Google-Smtp-Source: ABdhPJwMfx2G6pT/hud22GYmdI1mgp8Keve6b+hNH4/0EkXta0JVJ6vU+dcBZExhlylg820622d7aSWkjTk+ZoApeY0= X-Received: by 2002:a5b:611:: with SMTP id d17mr1779716ybq.196.1640055336569; Mon, 20 Dec 2021 18:55:36 -0800 (PST) MIME-Version: 1.0 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> <871r2yg3ob.fsf@oldenburg.str.redhat.com> In-Reply-To: <871r2yg3ob.fsf@oldenburg.str.redhat.com> From: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Date: Mon, 20 Dec 2021 18:55:25 -0800 Message-ID: Subject: Re: [PATCH] elf: Add __libc_get_static_tls_bounds [BZ #16291] To: Florian Weimer Cc: libc-alpha@sourceware.org, Adhemerval Zanella , GCC Patches , Dmitry Vyukov , Marco Elver , =?UTF-8?Q?Martin_Li=C5=A1ka?= , Jakub Jelinek Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-15.6 required=5.0 tests=BAYES_00, BODY_8BITS, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL 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: Tue, 21 Dec 2021 02:55:40 -0000 On Mon, Nov 29, 2021 at 11:30 AM Florian Weimer wrote: > > * 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=9Cexter= n > __thread int a[];=E2=80=9C and similar declarations, where the declare= d 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_c= ommon/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 a= dapt. __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 > --=20 =E5=AE=8B=E6=96=B9=E7=9D=BF