From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from phobos.denx.de (phobos.denx.de [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01]) by sourceware.org (Postfix) with ESMTPS id 56EBA3858415 for ; Wed, 6 Oct 2021 11:44:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 56EBA3858415 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=denx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=denx.de Received: from ktm (85-222-111-42.dynamic.chello.pl [85.222.111.42]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lukma@denx.de) by phobos.denx.de (Postfix) with ESMTPSA id 12C7283173; Wed, 6 Oct 2021 13:44:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=denx.de; s=phobos-20191101; t=1633520640; bh=F0q+WsCvKoTNsbByVvDh3mLtbkeIpTMmzxmkVySlE+k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=pnDf7GIrQAovWfc84femkJKiBb7vsOWfjHjDy9HpjjBy2ZVGorwZK1/i5zV2T8l8t xcqX0+90ytdcjixg41s9P+vlEAYhbvbDBlpcXi8Jj04Zf91QzeDmvOtaLxAnPyGTVq JSL0h/QzSzR6k7Y70CKyyiM4rlBOydoF6BgS03OVdhgyjbqKJBb9RL+kPZ1sya7ArK yrlIKuAbSmcSu23tIh6NARsQUl0q3a2WzX8xmqqHMdc2dxcwxtaKMyXkkSBtixBTNz Hzm9BV6eTAbw6asf/djZBUVJX/lk3qUjiUQ6WJSJdh1wGUp1MUArXFclYzZ1aypH1W q174g/Ojk4I1Q== Date: Wed, 6 Oct 2021 13:43:44 +0200 From: Lukasz Majewski To: Fangrui Song , Adhemerval Zanella , Florian Weimer , Joseph Myers , Andreas Schwab Cc: Carlos O'Donell , libc-alpha Subject: Re: [PATCH] dl: Use "adr" assembler command to get proper load address Message-ID: <20211006134344.63395242@ktm> In-Reply-To: <20211006110321.5f1a9610@ktm> References: <20210907131616.23472-1-lukma@denx.de> <20210907164906.yt6nonvfyhvbrx6p@google.com> <20210907193227.6047f9cc@ktm> <20210907174417.sctsswphsyae4mpc@google.com> <20211005094554.2f28d6bd@ktm> <20211006075721.qnv6qabroytcsido@google.com> <20211006110321.5f1a9610@ktm> Organization: denx.de X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/KsIAarOVqN+4w=bfKwfIR8H"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_BARRACUDACENTRAL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2021 11:44:04 -0000 --Sig_/KsIAarOVqN+4w=bfKwfIR8H Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear Community, Please find in-depth analyze about the issue: It was tested with Beagle Bone Black (BBB) and QEMU (the same binary rootfs images). (If needed I will upload images and script to run QEMU to some server for reproduction). Branch: https://github.com/lmajewski/y2038_glibc/commits/y2038_edge On working setup to trigger the core dump: /home/root/ld-linux-armhf.so.3 /sbin/init gdb ./ld-linux-armhf.so.3 core (and the /home/root/ld-linux-armhf.so.3 is the "broken" one). Not working (patch [1] not applied): =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D All the code is located in _dl_start in elf/rtld.c and elf/get-dynamic-info.h files: (gdb) p/x $r5 $46 =3D 0xb6fc8000 r5 is set from the elf_machine_load_address() Then we enter the elf_get_dynamic_info() 0xb6fc95fc 99 ADJUST_DYN_INFO (DT_SYMTAB); 0xb6fc95f8 <_dl_start+308>: 04 30 92 15 ldrne r3, [r2, #4] =3D> 0xb6fc95fc <_dl_start+312>: 05 30 83 10 addne r3, r3, r5 0xb6fc9600 <_dl_start+316>: 04 30 82 15 strne r3, [r2, #4] (gdb) p/x $r3 $63 =3D 0x410003f4 (gdb) p/x $r5 $64 =3D 0xb6fc8000 (gdb) si 0xb6fc9600 99 ADJUST_DYN_INFO (DT_SYMTAB); 0xb6fc95f8 <_dl_start+308>: 04 30 92 15 ldrne r3, [r2, #4] 0xb6fc95fc <_dl_start+312>: 05 30 83 10 addne r3, r3, r5 =3D> 0xb6fc9600 <_dl_start+316>: 04 30 82 15 strne r3, [r2, #4] (gdb) p/x $r3 $65 =3D 0xf7fc83f4 The above address is the kernel space one - so accessing it causes: "Program received signal SIGSEGV, Segmentation fault." (gdb) p/x $r3 $55 =3D 0xf7fc88e4 112 DO_ELF_MACHINE_REL_RELATIVE (map, l_addr, relative); =3D> 0xb6fc979c <_dl_start+728>: 08 10 13 e5 ldr r1, [r3, #-8] The problem is that elf_machine_load_address() returns wrong value - or maybe to say it differently - the one used afterwards by glibc is wrong. The correct one is, which corresponds to using 'adr' command (with patch [1] applied): 0xb6fc9508 in _dl_start (arg=3D0xbefffdf0) at rtld.c:545 545 bootstrap_map.l_addr =3D elf_machine_load_address (); =3D> 0xb6fc9508 <_dl_start+68>: 98 55 81 e5 str r5, [r1, #1432] ; 0x598 (gdb) p/x $r5 $12 =3D 0x75fc8000 Another issue is the way the assembler code is generated. With the working code one would have: (gdb) si 0xb6fc9608 99 ADJUST_DYN_INFO (DT_SYMTAB); 0xb6fc9600 <_dl_start+316>: 00 37 9f e5 ldr r3, [pc, #1792] ; 0xb6fc9604 <_dl_start+320>: 03 30 8f e0 add r3, pc, r3 =3D> 0xb6fc9608 <_dl_start+324>: d0 35 93 e5 ldr r3, [r3, #1488] ; 0x5d0 0xb6fc960c <_dl_start+328>: 00 00 53 e3 cmp r3, #0 (gdb) p/x $r3 $13 =3D 0xb6fff010 (gdb) p/x $pc $14 =3D 0xb6fc9608 (gdb)=20 In the above example the $r3 value is relative to $pc and $r5 is not used at all. The code which fails now looks like: 112 DO_ELF_MACHINE_REL_RELATIVE (map, l_addr, relative); =3D> 0xb6fc9870 <_dl_start+940>: 08 10 13 e5 ldr r1, [r3, #-8] (gdb) p/x l_addr $15 =3D 0x75fc8000 and everything works as expected. Questions: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1. I guess that different addressing assembler generated ($r3 calculation) is related to the address to be relocated (when the offset is too large the register is used - not the $pc itself). 2. I don't understand why values provided by elf_machine_load_address() differ? I would expect that those are equal. And help and input appreciated. Links: [1] - https://github.com/lmajewski/y2038_glibc/commit/e67e0f589b88a44be8f8b9b770b= 08950dd7e5bd5 readelf -e ld-linux-armhf.so.3=20 [10] .plt PROGBITS 41000994 000994 000050 04 AX 0 0= 4 [11] .text PROGBITS 41000a00 000a00 01fed0 00 AX 0 0= 64 [12] .rodata PROGBITS 410208d0 0208d0 004b24 00 A 0 0= 4 [13] .ARM.extab PROGBITS 410253f4 0253f4 000018 00 A 0 0= 4 [14] .ARM.exidx ARM_EXIDX 4102540c 02540c 0000c8 00 AL 11 0= 4 [15] .data.rel.ro PROGBITS 41036200 026200 000cf4 00 WA 0 0= 8 [16] .dynamic DYNAMIC 41036ef4 026ef4 0000c8 08 WA 5 0= 4 [17] .got PROGBITS 41036fbc 026fbc 000040 04 WA 0 0= 4 > Hi Fangrui, >=20 > > On 2021-10-05, Lukasz Majewski wrote: =20 > > >Hi Fangrui, > > > =20 > > >> > > > >> >I'm also wondering if similar issue is visible with "normal" - > > >> >i.e. not QEMU ARM run init. > > >> > > > >> >Maybe the "rough" environment in which /sbin/init is run is the > > >> >culprit? > > >> > =20 > > >> > > >> I had tested running ld.so and elf/ldconfig which covered the > > >> usage. > > >> > > >> I don't know. It needs some debugging from you:) =20 > > > > > >Could you share on which hardware (ARM) you run this change? > > > > > > > > >Best regards, > > > > > >Lukasz Majewski =20 > > =20 >=20 > Thanks for the info. >=20 > > I ran ld.so and elf/ldconfig with qemu-arm-static (built from =20 >=20 > Ok, so this was only the user mode emulation, not qemu-system-arm ? >=20 > > qemu/linux-user) (via binfmt_misc) on x86-64 Linux (Debian testing). > > I don't have real ARM hardware. =20 >=20 > The built image for BBB (Beagle Bone Black) also shows OOPs on the > real HW. >=20 > I'm debugging this now and share results asap. >=20 >=20 > Best regards, >=20 > Lukasz Majewski >=20 > -- >=20 > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: > lukma@denx.de Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de --Sig_/KsIAarOVqN+4w=bfKwfIR8H Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEgAyFJ+N6uu6+XupJAR8vZIA0zr0FAmFdi/AACgkQAR8vZIA0 zr1ScwgAr9M2yWzuY6Mr1jTWVJsVG+VHCens7O+NlCWJS7+OdTL1gFCD7SGF9012 VXAmgXmpj4U/wtF6mD9cohQnLPGt4Rn1bRizgOx2gID/wnuL9D5WW/xzuLkQv4K4 IKdvl8FC9WFrWoZpFmwToTZHQWra743M62FSGlkH53Lr4ZhXqGuCzsDJwQb7Ff34 WHCEGYoBHvj9dJhzM12pwZSrDo0QtIaaxt0/TRNhRSqZs+34QFy3srlcFQXkBwK0 E++YoJ4Hq5st8uUiRhdq9+Wlt8p4FaIKg/CZJk8qseGuBS0zr2CT0IJA6po/WtAR Ugh3jylDkXKPmHVrE548v3AvzrKYVw== =Nkyp -----END PGP SIGNATURE----- --Sig_/KsIAarOVqN+4w=bfKwfIR8H--