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.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,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 4504 invoked from network); 7 Sep 2023 14:43:07 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Sep 2023 14:43:07 -0000 Received: (qmail 32578 invoked by uid 550); 7 Sep 2023 14:43:03 -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 32546 invoked from network); 7 Sep 2023 14:43:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=s31663417; t=1694097771; x=1694702571; i=nullplan@gmx.net; bh=xDaTSswhsg+JbGd6SICrxvjn0lCOxxvejKdS/y1xQUI=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:References:In-Reply-To; b=hQL5sSsCn95JnWIZeVxfl9AaKwsFHYXHJrkXO55Xvb140VOBITRBgK5YT4gr6Jg74d6QTu/ +14XzPxnG3rtjs5qy8jwUH5n74eJ246zzeq1GbgmgPbZksPRMBzGFYCuzPUdqMhfDJfdf2UbY 4OYT2GAqVsDr4SoEW+qHfRnT7lP4JR5fmk5Uhrzh8eplIpkqAG22t334VpBd5tXRMZ4/9DXTS t9G/2vseOhQMHyFKSJax4bA5H06g1Ir4DztUX+yCGeknwm4G6gFfwiwCGO5KMvISjElONUrR7 aUeRcYohigmH2Xwsl26f1vfYbo1Eg3lXWbmwqMnVHiKGcp5ZxFeQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Date: Thu, 7 Sep 2023 16:42:50 +0200 From: Markus Wichmann To: musl@lists.openwall.com Cc: Peter Williams Message-ID: References: <1db459153e3f7be32cb469509c272977b9c2b381.camel@newton.cx> <20230907124828.GB4163@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230907124828.GB4163@brightrain.aerifal.cx> X-Provags-ID: V03:K1:CysqvKKU8V5eSNCmkn3dNXGwKg6b6Qfqz7w+cq+CcvVUZENO+gY YOy7H3gJuWMC6/fHZhgp76UmUklewicAs9kCzsLvEJJTsu4HJmIGOVHHSR82jLgZYXj5dFz 8+yEri4/mIP187vb9plBiIB+vL4GGFrAqADMAWw+SafvxpJ13LcHvZQeXzRTbEZioLmsta/ Wt/bcWSfZKtXZhLtTehhw== UI-OutboundReport: notjunk:1;M01:P0:BYTAU66c5DU=;T3W58EWEdpW7OYS+qTTqWsQo99B KqzzAiOoXH9N9A0aEsMMI8Lg6iOTvLJ8dXS6GBjnTIJ9cyzvr7jBiDYrCPwWbdDAfi+qqbiy3 tbtfv/AXTGY11AqjdsjXR1NyPM271mH7YbPLhhKWH6cy8uTvcUi3Ph4Mruu3uYP2TD73eSOZ4 QnAAXrmLMsMLM3KcyMf0mAwrEZYNp7dkoJqx7eA0cOmGQV22mVviK7DK074l2wGSq3C79UksS FLap++X9+4Iblo5tt9Lfi6t3bmbAP9R3vD1mEby8M2oYphBhcsgob2BJO1/JQZToAFnjPr5qV Zx/5ycvZ1GuekAtUxSrmbFcPy2fKFhYyYjHv9Hu9bZD1Z8ZXNgimFhDpGGsvnPN9eGT82bGJi Szx3l0mKyx0YioEa7bK4un42HlaIRsJV4gceZcgLE8VP3/MRxD8G8RBhD7UECI53xT45tSXmX 7PRboOxnLB7wi5YIzafOkhHukP56RRQz2bYuVwT8WyacWqscuvqkKBzCk++LPda5qH4TER6Qi SRp2TpkbUd13BzWM48wnbea2P7jo3Hdvf6RTN3ywTFAFaVHt5aS0NBjzrjU9QXZoXwmSHM/vY 3CsjbudpQ0df0W5p+1+Ffv/ShXwQsLvstne0I9gsZ21ghvl7dsbY4BlijC82Wl6dOfn96a/wj eGMYznUZOC8OFNOBk/MV+/D7u/Ym6WU9qoDu1UzZOjiAkYTgFayXwpZWadlkl/UmE3BBi8Buq aaR2eJ4+7f08UbzTZ7oK1B9fLQBshQ+UjnwAf6TPRcxJphR+hStRmvOefHFMt250W8YDLjlXI eIp2U5w9OHa1+nAAzlMbDr5fLI6sqm03/ppRgit124/XyteaWIQSy5U58aLzojUdfJtpgvTJu W8B0K3S5pav/VwXzOWfGkOWqU0E69c229tCeYo4u9R2PIk5MHYFl7APxV1Z2tuQMLV8q0Rv0z 2VRmiQ4L2m3TtXhg3dID428E4AU= Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] aarch64 sigsetjmp relocation truncation bug, maybe Am Thu, Sep 07, 2023 at 08:48:28AM -0400 schrieb Rich Felker: > 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). > > Rich No I am not sure. I wrote that patch before heading to work, without even test-compiling, and I don't know the first thing about arm64. But every architecture I have ever looked into at any depth had a shorter conditional branch than unconditional branch, and the linker normally presumes to be able to rearrange input code sections at will, at least for the branch length of an unconditional branch. Anything more usually requires more specialized code and specialized options to the compiler. That's why I wrote the patch in that way. Of course you are right that I did not think about the PLT, or a possible symbol interposition. However, the subroutine call to setjmp that was already in sigsetjmp also didn't. And the prior version of the code as well. So at least I didn't worsen the situation. Ciao, Markus