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.6 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,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 3825253d for ; Wed, 29 Jan 2020 18:42:12 +0000 (UTC) Received: (qmail 1474 invoked by uid 550); 29 Jan 2020 18:42: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 1441 invoked from network); 29 Jan 2020 18:42:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=zjvPGALVle8nELWWwUboUF0tW2azYPF01MWci/KmmLg=; b=mx0bLbkfyORe/pPbAv8hUf48TYvMKrk6tYef5fTiqep9S0AWSKsCaNBDT0hOlSNJE7 Fz6XKdwiPaeZjmq6ji9IKFD/meDkWzQ5vg6n4cOOpyC5QaCMhPped2on9OTUlMVdVN7r iNN1MuQDzDAPq6VvyN3B65oEXdtQ24ae1GYz0LGN2atmWSetU+LHRaRFyTVnLpe4mEma c6NQ3WVjcYqWKwLW9fiPBe+kdAucCyOn7WdVedG421AUIK1i5XtATQgbDPdX7dS86O5c 8zGtEbXNVUk94TWxvKC3W+virDbmESUBSoj0aD854f3F6NZgY3jFnVFXgy88TV550lsv Ed3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=zjvPGALVle8nELWWwUboUF0tW2azYPF01MWci/KmmLg=; b=umFvjxJbtDZQslsXeO+GqLELapfixYjAJmYQ+ulgsZ+w3phsoXXtruv+BASPXeT+3t 0DMN5r+MY+A7lUj/EPn/e4DgAl2SBXzOdPGhm4KOBXcmBsrHtami/JkhtM8uFJp2bz+B 08GocDqHChmeZwmlV4sBS+Nb9RwPtC0Vk+YWTzsQmdVAxEy1xETwRYbLziYDhE8top42 8v10xMJkfK/03dmPIDtqZ4NvOXtk0p052NVSw8GIaIxyQPUlHfTSgR444UOaWyavrkx6 X6J5k3vYoP3R+TCY24MltOmEoQQ/Jy0GsUfqqnKNGvptESevC9t2o25wCeuXlksn05Zc ubtA== X-Gm-Message-State: APjAAAUHFYTiFKYskQ3z+HK89utuPgidee7tXiWRGR4cV0q2ipk5WOee RZeiUSee3JLqkgmZafUkoA4ZD+QleHUGsdBcmMjKMYIIu/I= X-Google-Smtp-Source: APXvYqwrEfDEW4yAF8S4XyapN4YMRcwGhsdipeNQf06rz5Rpn0V9C2P46fNkITHxZ51BANtNrZSaZJgUbPShMAShKXs= X-Received: by 2002:a2e:85ce:: with SMTP id h14mr304395ljj.41.1580323317633; Wed, 29 Jan 2020 10:41:57 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?0JDQvdC00YDQtdC5INCQ0LvQsNC00YzQtdCy?= Date: Wed, 29 Jan 2020 21:41:46 +0300 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000fa53db059d4bb129" Subject: [musl] Static linking is broken after creation of DT_TEXTREL segment --000000000000fa53db059d4bb129 Content-Type: text/plain; charset="UTF-8" Hello. Please use the following docker image "puchuu/test_x86_64-gentoo-linux-musl". I will write here complete steps so everyone can reproduce this issue. docker run -it puchuu/test_x86_64-gentoo-linux-musl bash env-update && source /etc/profile echo "dev-libs/gmp static-libs" > /etc/portage/package.use/gmp MAKEOPTS='-j16' emerge -v dev-libs/gmp cd /tmp && wget " https://raw.githubusercontent.com/andrew-aladev/lzws/master/cmake/checks/GMP/main.c " gcc main.c -static -lgmp -o main && ./main We can see that "-static -lgmp" works perfect. gcc main.c /usr/lib/libgmp.a -o main && ./main /usr/lib/gcc/x86_64-gentoo-linux-musl/9.2.0/../../../../x86_64-gentoo-linux-musl/bin/ld: /usr/lib/libgmp.a(bdiv_q_1.o): warning: relocation against `__gmp_binvert_limb_table' in read-only section `.text' /usr/lib/gcc/x86_64-gentoo-linux-musl/9.2.0/../../../../x86_64-gentoo-linux-musl/bin/ld: warning: creating a DT_TEXTREL in object Segmentation fault (core dumped) We can see that direct usage of "/usr/lib/libgmp.a" provided DT_TEXTREL segment. MAKEOPTS='-j16' emerge -v gdb dev-vcs/git CFLAGS='-O0 -g -ggdb -ggdb3' CXXFLAGS='-O0 -g -ggdb -ggdb3' FEATURES='nostrip' MAKEOPTS='-j16' emerge -v musl gmp git clone git://git.musl-libc.org/musl --depth=1 --single-branch -b "v1.1.24" gcc -O0 -g -ggdb -ggdb3 main.c /usr/lib/libgmp.a -o main && gdb -ex=run -d musl ./main Program received signal SIGSEGV, Segmentation fault. 0x00007fe2f8c4f231 in do_relocs (dso=0x7fe2f8c8eb40 , rel=0x55af0a0cd568, rel_size=456, stride=3) at ldso/dynlink.c:423 423 *reloc_addr = (size_t)base + addend; (gdb) where #0 0x00007fe2f8c4f231 in do_relocs (dso=0x7fe2f8c8eb40 , rel=0x55af0a0cd568, rel_size=456, stride=3) at ldso/dynlink.c:423 #1 0x00007fe2f8c51e60 in reloc_all (p=0x7fe2f8c8eb40 ) at ldso/dynlink.c:1328 #2 0x00007fe2f8c53a03 in __dls3 (sp=0x7ffc82457260) at ldso/dynlink.c:1906 #3 0x00007fe2f8c52de6 in __dls2b (sp=0x7ffc82457260) at ldso/dynlink.c:1672 #4 0x00007fe2f8c52d4e in __dls2 (base=0x7fe2f8bba000 "\177ELF\002\001\001", sp=0x7ffc82457260) at ldso/dynlink.c:1650 #5 0x00007fe2f8c4e5a0 in _dlstart_c (sp=0x7ffc82457260, dynv=0x7fe2f8c8be20) at ldso/dlstart.c:147 #6 0x00007fe2f8c4e246 in _dlstart () from /lib/ld-musl-x86_64.so.1 #7 0x0000000000000001 in ?? () #8 0x00007ffc82458635 in ?? () #9 0x0000000000000000 in ?? () (gdb) info locals base = 0x561041462000 "\177ELF\002\001\001" syms = 0x5610414622c8 strings = 0x561041462478 "" sym = 0x0 name = 0x5610414624f8 "free" ctx = 0x7f9eea640b40 type = 8 sym_index = 0 def = {sym = 0x0, dso = 0x7f9eea640b40 } reloc_addr = 0x56104147cf79 <__gmpn_bdiv_q_1+25> sym_val = 0 tls_val = 0 addend = 131264 skip_relative = 0 reuse_addends = 0 save_slot = 0 (gdb) p laddr(dso, rel[0]) $27 = (void *) 0x56104147cf79 <__gmpn_bdiv_q_1+25> (gdb) p dso->loadmap $28 = (struct fdpic_loadmap *) 0x0 (gdb) p (dso->base + rel[0]) $29 = (unsigned char *) 0x56104147cf79 <__gmpn_bdiv_q_1+25> "\300" 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. 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. 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 issue. --000000000000fa53db059d4bb129 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello. Please use the following docker image "puchuu/= test_x86_64-gentoo-linux-musl". I will write here complete steps so ev= eryone can reproduce this issue.

docker run -it puchuu/t= est_x86_64-gentoo-linux-musl bash
env-update && sourc= e /etc/profile
echo "dev-libs/gmp static-libs" > /et= c/portage/package.use/gmp
MAKEOPTS=3D'-j16' emerge -v= dev-libs/gmp

gcc main.c -static -lgm= p -o main && ./main
We can see that "-static -lg= mp" works perfect.

gcc main.c /usr/lib/libgmp= .a -o main && ./main
/usr/lib/gcc/x86_64-gentoo-linux= -musl/9.2.0/../../../../x86_64-gentoo-linux-musl/bin/ld: /usr/lib/libgmp.a(= bdiv_q_1.o): warning: relocation against `__gmp_binvert_limb_table' in = read-only section `.text'
/usr/lib/gcc/x86_64-gentoo-linux-musl/9.2.= 0/../../../../x86_64-gentoo-linux-musl/bin/ld: warning: creating a DT_TEXTR= EL in object
Segmentation fault (core dumped)
We can see t= hat direct usage of "/usr/lib/libgmp.a" provided DT_TEXTREL segme= nt.

MAKEOPTS=3D'-j16' emerge -v gdb dev-vc= s/git
CFLAGS=3D'-O0 -g -ggdb -ggdb3' CXXFLAGS=3D'= -O0 -g -ggdb -ggdb3' FEATURES=3D'nostrip' MAKEOPTS=3D'-j16&= #39; emerge -v musl gmp
git clone git://git.musl-libc.org/musl --depth=3D1 -= -single-branch -b "v1.1.24"
gcc -O0 -g -ggdb -ggdb3= main.c /usr/lib/libgmp.a -o main && gdb -ex=3Drun -d musl ./main

Program received signal SIGSEGV, Segmentation f= ault.
0x00007fe2f8c4f231 in do_relocs (dso=3D0x7fe2f8c8eb40 <app>,= rel=3D0x55af0a0cd568, rel_size=3D456, stride=3D3) at ldso/dynlink.c:423423 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 *reloc_addr =3D (size_t)base + addend;
(gdb)= where
#0 =C2=A00x00007fe2f8c4f231 in do_relocs (dso=3D0x7fe2f8c8eb40 &l= t;app>, rel=3D0x55af0a0cd568, rel_size=3D456, stride=3D3) at ldso/dynlin= k.c:423
#1 =C2=A00x00007fe2f8c51e60 in reloc_all (p=3D0x7fe2f8c8eb40 <= ;app>) at ldso/dynlink.c:1328
#2 =C2=A00x00007fe2f8c53a03 in __dls3 (= sp=3D0x7ffc82457260) at ldso/dynlink.c:1906
#3 =C2=A00x00007fe2f8c52de6 = in __dls2b (sp=3D0x7ffc82457260) at ldso/dynlink.c:1672
#4 =C2=A00x00007= fe2f8c52d4e in __dls2 (base=3D0x7fe2f8bba000 "\177ELF\002\001\001"= ;, sp=3D0x7ffc82457260) at ldso/dynlink.c:1650
#5 =C2=A00x00007fe2f8c4e5= a0 in _dlstart_c (sp=3D0x7ffc82457260, dynv=3D0x7fe2f8c8be20) at ldso/dlsta= rt.c:147
#6 =C2=A00x00007fe2f8c4e246 in _dlstart () from /lib/ld-musl-x8= 6_64.so.1
#7 =C2=A00x0000000000000001 in ?? ()
#8 =C2=A00x00007ffc824= 58635 in ?? ()
#9 =C2=A00x0000000000000000 in ?? ()

(gdb) info locals
base =3D 0x561041462000 "\177ELF\002\001= \001"
syms =3D 0x5610414622c8
strings =3D 0x561041462478 "&= quot;
sym =3D 0x0
name =3D 0x5610414624f8 "free"
ctx =3D= 0x7f9eea640b40 <app>
type =3D 8
sym_index =3D 0
def =3D {sy= m =3D 0x0, dso =3D 0x7f9eea640b40 <app>}
reloc_addr =3D 0x56104147= cf79 <__gmpn_bdiv_q_1+25>
sym_val =3D 0
tls_val =3D 0
addend= =3D 131264
skip_relative =3D 0
reuse_addends =3D 0
save_slot =3D = 0

(gdb) p laddr(dso, rel[0])
$27 =3D (void *) 0= x56104147cf79 <__gmpn_bdiv_q_1+25>

(gdb)= p dso->loadmap
$28 =3D (struct fdpic_loadmap *) 0x0
(gdb) p (dso->base + rel[0])
$29 =3D (unsigned char *) 0= x56104147cf79 <__gmpn_bdiv_q_1+25> "\300"
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.

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

So I think that bug is inside musl itsel= f. Glibc container is the same situation works fine. I see no way to create= a workaround for this issue.

--000000000000fa53db059d4bb129--