From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by sourceware.org (Postfix) with ESMTPS id 933EB3858289 for ; Tue, 9 Apr 2024 14:47:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 933EB3858289 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 933EB3858289 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::b33 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712674033; cv=none; b=oMSinkyHa8cUZKbg/Hzi8Yx3EoctXDlDd61/jAUYFNKpXqWJWjwCJVky47fLaO2yhZnneVku8gtdIx7QrLyyVr2n6hJjgUf53/lW+GkGHSOwVKyVfKwHKnc8Y9xlT1bPq/PASdb7TqqTdO5v4nRr5FIxdKd8DS/HPjCrOWPgIEo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712674033; c=relaxed/simple; bh=VqHOmz39gKUZp0qDExEwLDYidPH9IaHrNFYyN8hdQRk=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=sxBLTcCXbIAnRac8Dac1LJCPoBSl6bU5aX7qT5lZfpZsqhE1e/yj75t5EbBgku11mF3GPDZLCqTYKQOuhafsshpbY6+wDqNBViZmz/xDFJQ7c6CVPNrFw09eQRUge1DQp/9xe0rZV9vLoPiSWFetiUSMDVqXWK1zipVWu4Unvhk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-yb1-xb33.google.com with SMTP id 3f1490d57ef6-dcd7c526cc0so5582160276.1 for ; Tue, 09 Apr 2024 07:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712674031; x=1713278831; darn=sourceware.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=RblabLZ4ImpSkH7COocHmsvypdMVuueedTlc4Sjhajs=; b=FwWvv0KNYeKWgsakZwFpbnDlZes6S3R0d8HkUAMloMqZlliIa/6ACD0bBytzTZxtXJ kRNVi1PeEyMn+Q3zOeNK9LSsQZNL5tDYCakxk1cn9hCJDGLbSUsAJuFyfV3kciv7fPYd fNiSP7KrcwzNthe4/bWpSwdUguxeXTGySYF98vNm1ByrAdJrXKIWOPbPNjw3V+MDjo1q lxj2mIHBmJ9BbFoOF4TzsnIosN04IqpvFYPbkh/N+DOVe91s07ZuJtXxJtcm24lR277H zLPHyPsVv2LO3TDDf0/WSd3YcdSlY0ZZhvyrb0hWKE1ZsQW1Lt2CJO2QoGsvNig8l6WQ EA4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712674031; x=1713278831; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RblabLZ4ImpSkH7COocHmsvypdMVuueedTlc4Sjhajs=; b=BQPa9/3jvkYU9aGa+khVbvBHugL5FWNfjcExcOLGJQiEIubIXPHmOpjmc84SaJrPYl oQnkdk+j4Hg9OGVHvUXBS6WckBGtfVXlzqSSkakKAoz9yvZEuRwnUqH5awnJcqn63IWk SWe0gqty1/rnOF7tfR5w5HvYhIwD7bxqP28vcix4vIUHrmVFg4LAhe09TtIYqcaS0x3R r2q3dsNrO4nY1LiY53A9kOCAmBHfQvzgn6frrV3ojUC6Zkybqh08RVxYnYyJWyfOSPTy XqpIiP11H4GhsOHSCWLApG0zjnsi0X+HYw8opZfmIGpRKlm/zTqfmQ7JuYxgn+Q+sv4S FtMA== X-Forwarded-Encrypted: i=1; AJvYcCWyQGeDL3pL3GrQteW7c7RsgZ9IhhqfnKxu9JZmLFL2hQ5TfJrpnGcXJSbdw4krnRd+eS3EFwHPgvK5HwJDkxDT6FUKG1mPoaon X-Gm-Message-State: AOJu0YyVJxVJnTf3WBsUUdGdLrNHEnrD9A1vnSBXXuppobxQoNEKkfS9 VdayTX8TR0ciJd5rpPZ9KFIAvwUf5ui3ATzbvLEq9Y46eECWvR7EevX49tIzoJc2g/ecO4yXJMs 0E5bG4JxvE6ouHuIZmkVYrqwD8LM= X-Google-Smtp-Source: AGHT+IE+R2lQf33r5/Y/kJDjkMV0p2rWdeR9jFTuA7VfEh1SLk1lkegn2LaBfBxWXG7uSCRH8kHG/pOTcA9/65WmHZc= X-Received: by 2002:a5b:912:0:b0:dcc:4cdc:e98e with SMTP id a18-20020a5b0912000000b00dcc4cdce98emr9556089ybq.5.1712674030680; Tue, 09 Apr 2024 07:47:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "H.J. Lu" Date: Tue, 9 Apr 2024 07:46:34 -0700 Message-ID: Subject: Re: [PATCH] aarch64: Remove ld.so __tls_get_addr plt usage To: Palmer Dabbelt Cc: adhemerval.zanella@linaro.org, szabolcs.nagy@arm.com, cristian@rodriguez.im, fweimer@redhat.com, libc-alpha@sourceware.org, vitalybuka@google.com, i@maskray.me, eugenis@google.com, kcc@google.com, dvyukov@google.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3013.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: On Tue, Apr 9, 2024 at 7:11=E2=80=AFAM Palmer Dabbelt = wrote: > > On Tue, 09 Apr 2024 07:03:45 PDT (-0700), adhemerval.zanella@linaro.org w= rote: > > > > > > On 09/04/24 05:30, Szabolcs Nagy wrote: > >> The 04/08/2024 13:57, Adhemerval Zanella Netto wrote: > >>> On 08/04/24 04:26, Szabolcs Nagy wrote: > >>>> The 04/07/2024 16:29, Cristian Rodr=C3=ADguez wrote: > >>>>> On Fri, Apr 5, 2024 at 11:59=E2=80=AFAM Szabolcs Nagy wrote: > >>>>>> The 04/05/2024 09:35, Adhemerval Zanella wrote: > >>>>>>> Use the hidden alias instead. > >>>>>>> > >>>>>>> Checked on aarch64-linux-gnu. > >>>>>> > >>>>>> does this change behaviour in case __tls_get_addr is interposed? > >>>>> > >>>>> Wut ? is that really supported.. I mean.. isn't that symbol prefix > >>>>> reserved for the implementation and any assumption about it is eith= er > >>>>> ID or UB? > >>>> > >>>> a behaviour can change even if it's not supported. > >>>> i did not try to imply that it should be supported. > >>>> > >>>> i know sanitizers interpose __tls_get_addr, because > >>>> https://sourceware.org/bugzilla/show_bug.cgi?id=3D16291 > >>>> i don't know if that hack works at all now for tlsdesc > >>>> (where the ld.so calls __tls_get_addr, not user code) > >>>> > >>>> my question was if we investigated this issue since it > >>>> is useful to document then in the commit msg (or news > >>>> entry if this affects users) > >>> > >>> This change 'breaks' the sanitizer trick to get the dynamic TLS, with > >>> this patch I now see: > >>> > >>> MemorySanitizer-AARCH64 :: dtls_test.c > >>> SanitizerCommon-asan-aarch64-Linux :: Linux/resize_tls_dynamic.cpp > >>> SanitizerCommon-msan-aarch64-Linux :: Linux/resize_tls_dynamic.cpp > >>> SanitizerCommon-tsan-aarch64-Linux :: Linux/resize_tls_dynamic.cpp > >>> > >>> And it does not fail on x86 only because it uses -mtls=3Dgnu as defau= lt > >>> (the same tests fail on x86 with -mtls=3Dgnu2). > >>> > >>> Now that GCC and distributions are aiming to use GNU2/DESC as the > >>> default TLS, this hack will also break on x86. So the question is > >>> whether we revert 050f7298e1ecc39887c329037575ccd972071255 and > >>> document that __tls_get_addr should be interposable, or move with thi= s > >>> change and try to come up with a possible solution for BZ#16291. > >>> > >>> I bringing this because we will have another two ABIs with tlsdesc > >>> support (loongarch and riscv). > >> > >> adding some sanitizer committers to cc. > >> > >> tl;dr: in the next glibc release tlsdesc will not call > >> __tls_get_addr in an interposable way in the dynamic tls > >> allocation case, unless somebody screems that this is needed. > >> (affects targets that may default to tlsdesc, but note that > >> the dynamic case only triggers with tlsdesc when a lot of > >> dlopened tls is used, otherwise static tls area is used) > > > > Just a note that this already true for x86 with -mtls=3Dgnu2 since > > 2.21. And now that distro are aiming to make it default, this issues > > will happen more often. > > > >> > >> i think it is also possible that we will use custom malloc > >> in ld.so which may be just as big change for the sanitizers. > >> (this can make tls access signal safe) > >> > >> i'm not against the change, but if we plan to add several > >> interposable hooks as in > >> https://sourceware.org/glibc/wiki/ThreadPropertiesAPI > >> then we might as well keep __tls_get_addr PLT for now. > >> > > > > I don't have a strong opinion, but what I really want is to have > > consistency over the architectures. Meaning that if we want to keep > > the __tls_get_addr PLT for sanitizer/runtime hooks, it would be good > > to revert the x86 change. > > > > It also means to document it properly somewhere and make the new > > RISC-V and loongarch follow the same guidelines. > > I also don't have a strong opinion on whether __tls_get_addr should be > interposable, but I'm happy to try and make the RISC-V port match > arm64/x86. I guess we're kind of safe for now as we don't have TLSDESC > merged, though I think we were getting pretty close there so we should > probbaly decide before we accidentally commit to an ABI. > > > I will take a look again on the ThreadPropertiesAPI, since it is has > > been more and more a demanding issue. We should add a __tls_get_addr glibc test if we decide it should be called via PLT. --=20 H.J.