From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 28206 invoked from network); 6 Oct 2023 04:08:47 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 6 Oct 2023 04:08:47 -0000 Received: (qmail 29882 invoked by uid 550); 6 Oct 2023 04:08:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 29845 invoked from network); 6 Oct 2023 04:08:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1696565309; x=1697170109; darn=lists.openwall.com; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=9TzaJgKFhKXNRrUJTFzb/6umUl89REBc23isdeomG6M=; b=XA+ql13UuLSSZTXpikkBX1Gdq5VY6OtqEW834R/3sLaWUc6BcAFljOlQ9ZJDTQ4k5h SPBuecWkUc/ftujwyn7tbsOrrXgatCeI4WAnQTMLa92BwmS7WUfIyWKAHBV4zOoq9ntS cn0+VSLhFvCLoAlJCqaiyey3sR+ZU3yetbzUnCFR1fWtr5bYLuFkBr8LHGizJ3UWKTmj /6X2ysinkwKRbXgZ4HLcIb/ukc9DJDtkrtgjePhubRA8Zl1+w2LggWK/i/LrY6RucCt5 ly/eZkdjievo+WmRbyME+3ED5N65vJMcq73RBP27h0YwEosurN8jNiSlh58CnwxDq84N YF1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696565309; x=1697170109; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=9TzaJgKFhKXNRrUJTFzb/6umUl89REBc23isdeomG6M=; b=jo7Uf4H0J7EtnFapV9aK2c9mMJYEWPSxXSpargxH2yi5M7RRuLaCAqQErRTnpi2RhL 0m6mxajzFJWxadl368dsN/iKe9qskSowLGodPe1kgf8LFmEMY0sMpYAyOZhKcQ8y6uAr O4vFAmTD7x7gtCeRg0YCrvA+nUmfZSesXgaFXyuof0XHaewtp8M73ax3vs0wB/ScbQ7m ugy/pXzg2gwXGRTP9UnpMI7advtK/wurmlQ5UAW19GRqzMPm9vvU/D7q7/FWXCgViDuX 7HmhFQZoDxNU3IDbSmytjbGVRQDscBxPoR8u57dG8w69mUl6txzrNTuk6kEVmNusm3rs w82A== X-Gm-Message-State: AOJu0Ywzq87NnlVIPH5XHgiYN59gYD56/2OgUu+ULo8uIrQxJih394/C zio8/01wXvSQHkjO0Vc3Sre1Q9nNbCicTKDLB4GIeS3Zj7o= X-Google-Smtp-Source: AGHT+IHpG/t/XDaAOQdR2qtDj5DtLZHF0/d8rAzMdg5qEKFj9UsG8FOa2msacw4NQ/hEJ4PKpmjpVMycNuxytun1uwI= X-Received: by 2002:a05:6e02:1c29:b0:34f:efde:ec7c with SMTP id m9-20020a056e021c2900b0034fefdeec7cmr8377156ilh.28.1696565309010; Thu, 05 Oct 2023 21:08:29 -0700 (PDT) MIME-Version: 1.0 From: Rui Ueyama Date: Fri, 6 Oct 2023 13:08:18 +0900 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000094fa3f0607046400" Subject: [musl] arm32 tlsdesc bug --00000000000094fa3f0607046400 Content-Type: text/plain; charset="UTF-8" Hi, I think there's a bug in musl's TLSDESC implementation for ARM32. TLSDESC uses two consecutive GOT slots to store a function pointer and its argument. Usually, the function pointer is stored in the first slot and the argument in the second. However, on ARM32, the order is reversed; the argument is stored in the first slot. If a TLSDESC relocation has a non-zero addend, it's applied to the function argument and not to the function pointer. That means, for an ABI that uses the REL-type relocations (as opposed to RELA-type), the addend should be stored to the location where the function argument is stored, and that's the first slot on ARM32. So, I believe we need something like this. diff --git a/ldso/dynlink.c b/ldso/dynlink.c index ceca3c98..254fa5b8 100644 --- a/ldso/dynlink.c +++ b/ldso/dynlink.c @@ -513,11 +513,17 @@ static void do_relocs(struct dso *dso, size_t *rel, size_t rel_size, size_t stri case REL_TPOFF_NEG: *reloc_addr = def.dso->tls.offset - tls_val + addend; break; #endif case REL_TLSDESC: - if (stride<3) addend = reloc_addr[1]; + if (stride<3) { +#ifdef TLSDESC_BACKWARDS + addend = reloc_addr[0]; +#else + addend = reloc_addr[1]; +#endif + } if (def.dso->tls_id > static_tls_cnt) { struct td_index *new = malloc(sizeof *new); if (!new) { error( "Error relocating %s: cannot allocate TLSDESC for %s", --00000000000094fa3f0607046400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think there's a bu= g in musl's TLSDESC implementation for ARM32.

= TLSDESC uses two consecutive GOT slots to store a function pointer and its = argument. Usually, the function pointer is stored in the first slot and the= argument in the second. However, on ARM32, the order is reversed; the argu= ment is stored in the first slot.

If a TLSDESC rel= ocation has a non-zero addend, it's applied to the function argument an= d not to the function pointer. That means, for an ABI that uses the REL-typ= e relocations (as opposed to RELA-type), the addend should be stored to the= location where the function argument is stored, and that's the first s= lot on ARM32.

So, I believe we need something like= this.

diff --git a/ldso/dynlink.c b/ldso/dynlink.c
= index ceca3c98..254fa5b8 100644
--- a/ldso/dynlink.c
+++ b/ldso/dynli= nk.c
@@ -513,11 +513,17 @@ static void do_relocs(struct dso *dso, size_t= *rel, size_t rel_size, size_t stri
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 case REL_TPOFF_NEG:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 *reloc_addr =3D def.ds= o->tls.offset - tls_val + addend;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 break;
=C2=A0#endif
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case REL_TLSDESC:- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 if (stride<3) addend =3D reloc_addr[1];
+ =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (stride<3) {=
+#ifdef TLSDESC_BACKWARDS
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 addend = =3D reloc_addr[0];
+#else
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 addend =3D = reloc_addr[1];
+#endif
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (def.dso->tls_id >= ; static_tls_cnt) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 struct td_index= *new =3D malloc(sizeof *new);
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 if (= !new) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 error(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 "Error relocating %s: cannot allocate TLSDESC for %s",
=
--00000000000094fa3f0607046400--