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=-1.6 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,URIBL_BLACK autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14357 invoked from network); 7 Sep 2023 19:49:52 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2023 19:49:52 -0000 Received: (qmail 24264 invoked by uid 550); 7 Sep 2023 19:49:48 -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 24216 invoked from network); 7 Sep 2023 19:49:47 -0000 Date: Thu, 7 Sep 2023 21:49:35 +0200 From: Szabolcs Nagy To: Rich Felker Cc: musl@lists.openwall.com, Peter Williams Message-ID: <20230907194935.GG3448312@port70.net> Mail-Followup-To: Rich Felker , musl@lists.openwall.com, Peter Williams References: <1db459153e3f7be32cb469509c272977b9c2b381.camel@newton.cx> <20230907124828.GB4163@brightrain.aerifal.cx> <20230907132851.GC4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20230907132851.GC4163@brightrain.aerifal.cx> Subject: Re: [musl] aarch64 sigsetjmp relocation truncation bug, maybe * Rich Felker [2023-09-07 09:28:52 -0400]: > On Thu, Sep 07, 2023 at 08:48:28AM -0400, Rich Felker wrote: > > On Thu, Sep 07, 2023 at 05:08:13AM +0200, Markus Wichmann wrote: > > > Am Wed, Sep 06, 2023 at 08:46:32PM -0400 schrieb Peter Williams: > > > > If I'm understanding correctly, the complaint is that a=C2=A0branch= in > > > > sigsetjmp that invokes setjmp=C2=A0is too far away from the definit= ion of > > > > setjmp. My very handwavey idea is that maybe for some reason my pro= gram > > > > is causing the linker to want to locate setjmp() and sigsetjmp() re= ally > > > > far away from each other. If that's right, perhaps it would be poss= ible > > > > to modify the assembler code to be able to handle such a situation? > > >=20 > > > I'm guessing the same. Pretty much all architectures have shorter > > > conditional than unconditional branches. That is why branches to other > > > files (technically to other sections) should always be unconditional.= I > > > am attaching a simple patch that should help with the situation. > > >=20 > > > Ciao, > > > Markus > >=20 > > > From dd227e22a5337d54e1cb0838410bca6672c76c43 Mon Sep 17 00:00:00 2001 > > > From: Markus Wichmann > > > Date: Thu, 7 Sep 2023 05:01:23 +0200 > > > Subject: [PATCH] Make branch to external symbol unconditional. > > >=20 > > > Conditional branches have a shorter branch length than unconditional > > > ones, and almost all ABIs require unconditional branches to external > > > symbols. Otherwise linkers may create broken binaries. > > > --- > > > src/signal/aarch64/sigsetjmp.s | 4 +++- > > > 1 file changed, 3 insertions(+), 1 deletion(-) > > >=20 > > > diff --git a/src/signal/aarch64/sigsetjmp.s b/src/signal/aarch64/sigs= etjmp..s > > > index 75910c43..9a28e395 100644 > > > --- a/src/signal/aarch64/sigsetjmp.s > > > +++ b/src/signal/aarch64/sigsetjmp.s > > > @@ -4,7 +4,7 @@ > > > .type __sigsetjmp,%function > > > sigsetjmp: > > > __sigsetjmp: > > > - cbz x1,setjmp > > > + cbz x1,1f > > >=20 > > > str x30,[x0,#176] > > > str x19,[x0,#176+8+8] > > > @@ -19,3 +19,5 @@ __sigsetjmp: > > >=20 > > > .hidden __sigsetjmp_tail > > > b __sigsetjmp_tail > > > + > > > +1: b setjmp yeah, this looks good except the commit message can be improved. conditional branch has +-1M reach, unconditional branch has +-128M reach and the linker inserts a veneer if unconditional branch goes further than that (i.e. it can go arbitrarily far). setjmp is a local symbol to libc (or in case of static linking to the exe), so using unconditional branch is perfectly fine if we ensure the linker does not move the symbols far (e.g. putting the two symbols in the same object file or into the same small section is enough). this depends on that user code cannot interpose setjmp (link namespace violation) and setjmp in libc does not use plt. note that aarch64 libc.so text is < 1M so we can compile it with -mcmodel=3Dtiny code model and then the compiler would emit cond branch for libc symbols. but .lo objects built like that are not suitable for libc.a. the simple b setjmp is the reasonable fix for now. > > Are you sure this is the actual problem? I think it's that the aarch64 > > (and several other archs) version of sigsetjmp is wrongly using the > > public setjmp symbol whose definition is possibly provided by a PLT > > thunk in the main program, rather than either setjmp@PLT (which would > > necessarily be the right local call point to use) or the hidden > > ___setjmp symbol that exists for this purpose (which i386, for > > example, uses). >=20 > Hmm, no, that seems to be a separate issue. The reported issue is > indeed a large static link where PLT stuff should not come into play. > So I think the cbz limited-range is indeed the issue. >=20 > Rich