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.129.124]) by sourceware.org (Postfix) with ESMTPS id D9DBF3858D32 for ; Wed, 10 Apr 2024 08:23:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D9DBF3858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D9DBF3858D32 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712737443; cv=none; b=QF7sXdVKz65b4Mp4CeP3TX8jtdx7wY1z5MKKyXJNYxw2vwc61RMJ6G4VJzS6Zo+Og87rILYd4B9+I9/4UQJzxqOA5bOCcTJ5po2GMx7lXhppJMJym4JpKMCcTzAwpJRTjBzE0SFjJ9ikOb1wZkNLMTe4zZJexZZhHApz7xZPm6M= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712737443; c=relaxed/simple; bh=w5Lzy0vTf1RUa5Hp37anmTetnjHEOA1pMFRyn09WSGk=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=pvdudcm12BqlwGiAGl9bfepjTVONmANNKAgbh1/vnUiBYIDlThNP7xi9b1blrAkpwS37lZq4+Q9jdd0AXnRHN/QiaSc1GYiFam1F1StBrCv5VdL5O3ymKEAMSRXoaUpnqQac8JeXxxMAx6tt92NQ6W0qtRgeN23uP6Yw51I9D6Y= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712737438; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iADamAqx8AQA+vK7KrS90R25Gftmtoh08f6l3IjykkA=; b=hYPh7civn2ZOVw5yNU3N92VcTR+ipwT9kQ+QyJYIstEHYdYzFppqrInd7swFhgjsZF03KV TgNY8coc64qYeDB+IZoajaHX+jTtIXRZrfZ8mJ7nStylAWUW4i+2JNHX1YUIAfDBWq886M xnSwDSF2dYjYV3/icd1WdpP7wE4jXZ4= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-403-7721drPfNiKHN1PJDShnXw-1; Wed, 10 Apr 2024 04:23:53 -0400 X-MC-Unique: 7721drPfNiKHN1PJDShnXw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8E03029AA3B5; Wed, 10 Apr 2024 08:23:52 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.109]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4D0E32166B32; Wed, 10 Apr 2024 08:23:50 +0000 (UTC) From: Florian Weimer To: Fangrui Song Cc: Adhemerval Zanella Netto , Szabolcs Nagy , Cristian =?utf-8?Q?Rodr=C3=ADguez?= , "H.J. Lu" , libc-alpha@sourceware.org, Vitaly Buka , Fangrui Song , Evgenii Stepanov , Kostya Serebryany , Dmitry Vyukov Subject: Re: [PATCH] aarch64: Remove ld.so __tls_get_addr plt usage In-Reply-To: (Fangrui Song's message of "Tue, 9 Apr 2024 10:50:38 -0700") References: <20240405123550.1748641-1-adhemerval.zanella@linaro.org> Date: Wed, 10 Apr 2024 10:23:44 +0200 Message-ID: <87a5m14odr.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 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=-5.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_INFOUSMEBIZ,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Fangrui Song: > Last time I analyzed the __tls_get_addr interceptor in sanitizers, I > have made quite some notes at > https://maskray.me/blog/2021-02-14-all-about-thread-local-storage#why-doe= s-compiler-rt-need-to-know-tls-blocks > > Yes, an interceptor is needed. There's no guarantuee that TLS access goes through a regular function call, so any design that relies on such a call happening is fundamentally broken. Quoting from your article: | Note: if the allocation is rtld/libc internal and not intercepted, | there is no need to unpoison the range. The associated shadow is | supposed to be zeros. However, if the allocation is intercepted, the | runtime should unpoison the range in case the range reuses a previous | allocation which happens to contain poisoned bytes. | | In glibc, _dl_allocate_tls and _dl_deallocate_tls call malloc/free | functions which are internal and not intercepted, so the allocations | are opaque to the runtime and the shadow bytes are all zeroes. I don't think this is accurate. We call the application malloc/free for non-main threads after initialization. Having an accurate description of sanitizer needs in this area would be really helpful, but I think we are not quite there yet. (This is different from an API description.) I think there are several aspects here: (a) Avoid false errors for bounds checks for Address Sanitizer. (b) Support pointer discovery for Leak Sanitizer (essentially conservative garbage collection). (c) Avoid false data race reports for Thread Sanitizer after TLS reuse from one thread for a different thread (only with non-overlapping lifetimes). Based on your description, I'm not sure if (a) is actually a problem. If we don't use application malloc for TLS allocations, bounds checking is bypassed apparently? And if we use malloc, out-of-bounds accesses would be actual bugs. Aspect (b) is a real issue. Could we address that by allocating the TCB (with static TLS) and all dynamic TLS with application malloc (or rather, memalign/aligned_alloc), and keep a pointer to the allocation on the thread stack? Then a conservative collector could find it, and scan it for pointers. A gap remains for the main thread, whose TCB is not allocated using application malloc=E2=80=94and can't be, as the application malloc itself very likely depends on the TCB already being there. We could switch TCBs after allocating another one with malloc, but that would require some hand-off protocol, I believe. Maybe it's better to register early allocations with the sanitizer directly, using some appropriate API. For (c), we could just stop caching TCBs after thread exit. If we call free, and reallocate for the new thread, that should avoid the false data race. This issue does not affect the main thread. Based on that, I don't think we need to support discovery of TLS areas, or export any other internal implementation details. We just need to use more malloc within glibc if we detect an active sanitizer, and find a way to make the TCB allocation of the main thread known to the sanitizer. Thanks, Florian