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=-2.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,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 df2ac0fb for ; Wed, 29 Jan 2020 20:09:11 +0000 (UTC) Received: (qmail 11786 invoked by uid 550); 29 Jan 2020 20:09:09 -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 11768 invoked from network); 29 Jan 2020 20:09:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=mK/OKR6g2kOEl/NrvomcvuTly7Ff/UKokZfWv5IWAxM=; b=Ab06+yZwDYKoADAPTIybsBn/X8nnqPEky4smxRdkK1wWIbOPgpNUS9TQy+x+Y8oKeP RQF1g6LE6EqiimnscaU1LETcsUiM2mOLYUQwu5E13W7VpO4eVry4OGEvCGBUPc6o7tzT ol15F6VxaNYI7UV7s2VkgAQ8dJbTtArWrYUpXFhx5ebZn/CW1rWE7TqRJ5AVK11CgJ16 FhjoRlS+zRSL4IS73X9mpTB77SDMtxPRzDMmE12WkWfGreMqTkMuI/wjRscvS1RhPyBI f7AxTyv5Mtaz9C15sBZ+5guLBF63wy1vCiYK96eTw7Vs4sxmU/ArIbCpeaLIhnZlaqLY RVdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=mK/OKR6g2kOEl/NrvomcvuTly7Ff/UKokZfWv5IWAxM=; b=sMgiOif3kuyyiUdnCuEeaPoaRvwIydKkKvfGUUOQJ4dBeR/sVAGz0cgDq8BcI48F1c EuzpJIAlXFI3uEOEs4vTu5X9DYPHPnRO8ADH/TtL6rrjl2YvQWWpFeq3xe5fauaxn2SM Vh2r18a3i0dvLqeCngzwjUqYHPkGnPdo6PRCOeqLjCq0nNljWL9BZrOUMBO5u7MzWCRU DEd/7t1MqcHvoZ2CP2h6XUNziht6EKgi0Y4mkoL7gBp6oTxfF4vxMBFEG4vExvs0GKon 4Q8+7y7QRZt5P2n4+H58frZ93K8+jxl4WveYsag0uCjyHh/5Okc88H5qQ4WwMsyb666t vMIQ== X-Gm-Message-State: APjAAAXuKdPaIQqUcpuHDygozqr0tSNe9GMdt4/i9CAip83WCBrJM2c8 SuJ14Xcu5hcsaJ+Isds4lfISd/bcdvNE7yS3qJwEkCbwK28= X-Google-Smtp-Source: APXvYqxJokT0wrJf02b1UjdJyWBRPpfXxP6ZA41r97PZt8Wsdt5xyl+aPYPosbrvZLwV8JuyHrT1tLBvj06x9bMgVDA= X-Received: by 2002:ac2:4945:: with SMTP id o5mr501159lfi.93.1580328537776; Wed, 29 Jan 2020 12:08:57 -0800 (PST) MIME-Version: 1.0 References: <20200129191946.GI2020@voyager> In-Reply-To: <20200129191946.GI2020@voyager> From: =?UTF-8?B?0JDQvdC00YDQtdC5INCQ0LvQsNC00YzQtdCy?= Date: Wed, 29 Jan 2020 23:08:46 +0300 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="0000000000001f6617059d4ce981" Subject: Re: [musl] Static linking is broken after creation of DT_TEXTREL segment --0000000000001f6617059d4ce981 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Ooh boy, why would you do this? When there's a perfectly good -lgmp just waiting for you. Usage of "/usr/lib/libgmp.a" directly is not forbidden by any toolchain or build system. Moreover it is recommended by cmake. You can google for "target_link_libraries( site:github.com" and found millions of software that uses something like: find_library(EXTERNAL_LIB) target_link_libraries(something ${EXTERNAL_LIB_FOUND}) > 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=3D'-asm' emerge -v1 gmp", assembly is broken, will report it to gmp upstream. But this is not a fix for the issue= . > Iterate over the apps PHDRs and remove write protection from all RO segments? So libc knows that file is mapped as readonly and should not try to write into readonly pointers. Libc can do the following: 1. Ignore impossible relocations. 2. Add a warning to stderr and still ignore impossible relocations. 3. do abort, user will receive SIGABRT and understand that he uses libc in a wrong way. Segfault is not an acceptable answer. Thank you. =D1=81=D1=80, 29 =D1=8F=D0=BD=D0=B2. 2020 =D0=B3. =D0=B2 22:20, Markus Wich= mann : > On Wed, Jan 29, 2020 at 09:41:46PM +0300, =D0=90=D0=BD=D0=B4=D1=80=D0=B5= =D0=B9 =D0=90=D0=BB=D0=B0=D0=B4=D1=8C=D0=B5=D0=B2 wrote: > > gcc main.c /usr/lib/libgmp.a -o main && ./main > > Ooh boy, why would you do this? When there's a perfectly good -lgmp just > waiting for you. > > > warning: creating a DT_TEXTREL in object > > 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. > > > We can see that "laddr" provided pointer to "dso->base + rel[0]", than > > switch tried to override it's value and segfault appeared. Pointer is > > wrong, most likely readonly. > > > > Pointer is correct, but memory should have been mapped writable. More on > this in a bit. > > > You can replace "gcc" with "clang" and everything will be the same. > Updated > > binutils to most recent version 2.33.1 and rebuilt toolchain - nothing > > changed. Pointer is still invalid and SEGV_ACCERR appears. > > > > Of course. The issue is a relocation inside a read-only segment. > Binutils and compiler are not malfunctioning. > > > So I think that bug is inside musl itself. Glibc container is the same > > situation works fine. I see no way to create a workaround for this issu= e. > > Well, the remedy is obvious: Get rid of the TEXTREL. It is usually > caused by bad assembly source code, and fixable with only minor > knowledge of the details. Consult the search engine of your least > distrust for more information on this. > > Regarding the actual problem though, the problem here is that DT_TEXTREL > is handled only in map_library(), so it is not handled for kernel mapped > DSOs. Which isn't a problem for libc or the VDSO, but the app itself > might be TEXTREL (and is, in this case), and that isn't handled. How, > though? Iterate over the apps PHDRs and remove write protection from all > RO segments? > > And one more question: Since musl resolves all relocations immediately, > couldn't we write-protect TEXTREL modules after relocating them? > Provided no unresolved relocations remain, of course. > > Ciao, > Markus > --0000000000001f6617059d4ce981 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> Ooh boy, why would you do this? When there's a pe= rfectly good -lgmp just waiting for you.

Usage of "= /usr/lib/libgmp.a" directly is not forbidden by any toolchain or build= system. Moreover it is recommended by cmake. You can google for "targ= et_link_libraries( site:github.com" = and found millions of software that uses something like:

find_library(EXTERNAL_LIB)
target_link_libraries(something= ${EXTERNAL_LIB_FOUND})

> The warning is ju= stified, you usually do not want to do this. With a TEXTREL, the code has t= o 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, th= e remedy is obvious: Get rid of the TEXTREL.

Yes, = I've found a workaround: "USE=3D'-asm' emerge -v1 gmp"= ;, assembly is broken, will report it to gmp upstream. But this is not a fi= x for the issue.

> Iterate over the apps PHDRs = and remove write protection from all RO segments?

<= div>So libc knows that file is mapped as readonly and should not try to wri= te into readonly pointers. Libc can do the following:

<= div>1. Ignore impossible relocations.
2. Add a warning to stderr = and still ignore=C2=A0impossible relocations.
3. do abort, us= er will receive=C2=A0SIGABRT and understand that he uses libc in a wrong wa= y.

Segfault is not an acceptable answer.

Thank you.

=D1=81=D1=80, 29 =D1=8F=D0=BD=D0=B2. 2020 = =D0=B3. =D0=B2 22:20, Markus Wichmann <nullplan@gmx.net>:
On Wed, Jan 29, 2020 at 09:41:46PM +0300, =D0=90=D0=BD=D0=B4= =D1=80=D0=B5=D0=B9 =D0=90=D0=BB=D0=B0=D0=B4=D1=8C=D0=B5=D0=B2 wrote:
> gcc main.c /usr/lib/libgmp.a -o main && ./main

Ooh boy, why would you do this? When there's a perfectly good -lgmp jus= t
waiting for you.

> warning: creating a DT_TEXTREL in object

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.

> We can see that "laddr" provided pointer to "dso->ba= se + rel[0]", than
> switch tried to override it's value and segfault appeared. Pointer= is
> wrong, most likely readonly.
>

Pointer is correct, but memory should have been mapped writable. More on this in a bit.

> You can replace "gcc" with "clang" and everything = will be the same. Updated
> binutils to most recent version 2.33.1 and rebuilt toolchain - nothing=
> changed. Pointer is still invalid and SEGV_ACCERR appears.
>

Of course. The issue is a relocation inside a read-only segment.
Binutils and compiler are not malfunctioning.

> So I think that bug is inside musl itself. Glibc container is the same=
> situation works fine. I see no way to create a workaround for this iss= ue.

Well, the remedy is obvious: Get rid of the TEXTREL. It is usually
caused by bad assembly source code, and fixable with only minor
knowledge of the details. Consult the search engine of your least
distrust for more information on this.

Regarding the actual problem though, the problem here is that DT_TEXTREL is handled only in map_library(), so it is not handled for kernel mapped DSOs. Which isn't a problem for libc or the VDSO, but the app itself might be TEXTREL (and is, in this case), and that isn't handled. How, though? Iterate over the apps PHDRs and remove write protection from all RO segments?

And one more question: Since musl resolves all relocations immediately,
couldn't we write-protect TEXTREL modules after relocating them?
Provided no unresolved relocations remain, of course.

Ciao,
Markus
--0000000000001f6617059d4ce981--