[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200203040540.GM1663@brightrain.aerifal.cx>
Date: Sun, 2 Feb 2020 23:05:40 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: 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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
