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 e45aaa95 for ; Mon, 3 Feb 2020 04:05:55 +0000 (UTC) Received: (qmail 7274 invoked by uid 550); 3 Feb 2020 04:05:54 -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 7256 invoked from network); 3 Feb 2020 04:05:53 -0000 Date: Sun, 2 Feb 2020 23:05:40 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200203040540.GM1663@brightrain.aerifal.cx> References: <20200129191946.GI2020@voyager> <20200130170249.GK2020@voyager> <20200203031036.GL1663@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200203031036.GL1663@brightrain.aerifal.cx> 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 Sun, Feb 02, 2020 at 10:10:36PM -0500, Rich Felker wrote: > 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? OK, --with-pic fixes it, but not for users using slibtool in place of the shipped libtool since gmp is pulling the flag out of libtool internals somehow and usint that to decide how to generate its preprocessed asm sources. Eew. Do you (or anyone else) know a way to force gmp's asm preprocessor to always pick the PIC version of the asm, without poking at libtool internals? I'd like to fix this with gmp patches we could ship in mcm, but if there's no easy solution immediately found I'll probably just add --disable-assembly for now. Rich