From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id d82eabfe for ; Mon, 3 Feb 2020 03:10:51 +0000 (UTC) Received: (qmail 15566 invoked by uid 550); 3 Feb 2020 03:10:49 -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 15548 invoked from network); 3 Feb 2020 03:10:49 -0000 Date: Sun, 2 Feb 2020 22:10:36 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200203031036.GL1663@brightrain.aerifal.cx> References: <20200129191946.GI2020@voyager> <20200130170249.GK2020@voyager> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200130170249.GK2020@voyager> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment On Thu, Jan 30, 2020 at 06:02:49PM +0100, Markus Wichmann wrote: > > > The warning is justified, you usually do not want to do this. With a > > TEXTREL, the code has to be mapped as writable, so now programming errors > > and exploits can change the executable code. > > > > This is warning from ld, not from musl. Segfault is not an acceptable > > message from libc. Libc should not try to write into readonly pointer. > > > > > Well, the remedy is obvious: Get rid of the TEXTREL. > > > > Yes, I've found a workaround: "USE='-asm' emerge -v1 gmp", assembly is > > broken, will report it to gmp upstream. But this is not a fix for the issue. > > > > There are several ways to achieve this. Getting rid of the assembly is > one such way. In another answer you also advocated for --with-pic. My > solution would probably have been to patch the code to never emit text > relocations in the first place, which is achieved the same way in the > end. Users have hit this issue in musl-cross-make when the compiler being used to compile the toolchain is default-pie and system-wide gmp is not being used, except that it's a link error (as it should be) which mpfr's configure script hits when testing linking against libgmp, rather than runtime crash. I'll probably end up having mcm pass --with-pic to GCC's top-level configure, but I see this will be picked up by some other libs like libcc1, which oddly aren't failing for the same reason. Any idea why? Is this the right fix for mcm? What could/should be done to unbreak gmp with default-pie toolchains? Is it a bug in the version of libtool they're using or a bug in gmp? Rich