From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id D845D3858D28 for ; Fri, 3 Mar 2023 22:17:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D845D3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org References: <20230302112519.914641-1-arsen@gentoo.org> <87bklajbna.fsf@oldenburg.str.redhat.com> User-agent: mu4e 1.8.14; emacs 30.0.50 From: Arsen =?utf-8?Q?Arsenovi=C4=87?= To: Florian Weimer Cc: libc-alpha@sourceware.org, Carlos O'Donell , Gentoo Toolchain Subject: Re: [PATCH] elf,nptl: Add -z lazy -z norelro to tests that need it Date: Fri, 03 Mar 2023 22:54:47 +0100 In-reply-to: <87bklajbna.fsf@oldenburg.str.redhat.com> Message-ID: <86y1odlbss.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Florian Weimer writes: > * Arsen Arsenovi=C4=87 via Libc-alpha: > >> Some toolchains, such as that used on Gentoo Hardened, set -z now -z >> relro out of the box. These flags break tests that rely on fixups in >> underlinked libraries being applied after a dlopen happens. > > I'm surprised that -z norelro is ever required. Why isn't -z lazy > enough? If ld.so crashes because it attempts to apply relocations after > the fact, woudln't that be an ld.so bug (or a linker bug that sets up > the RELRO segment incorrectly)? Hm. Something went awry while I was debugging this. I looked at a test again just now and noticed that the symbols some of these tests were crashing on came from libc (dlopen here) while loading constload2 (which is dlopen'd from constload1). The backtrace contains a PLT trampoline which then fixups dlopen inside the RELRO segment. I take it dlopen@got[plt] is not supposed to be in the RELRO range? I could have sworn this failed when fixing up bar (void) as a result of constload2 dlopening constload3... but maybe that was a different failure. Let's put this patch on hold while I investigate further. FWIW, this should be easy to reproduce by building with CC=3D'gcc =2DWl,-z,relro,-z,now' or so, I think. Thanks, sorry about the fuss. =2D-=20 Arsen Arsenovi=C4=87 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOcEARYKAI8WIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCZAJyA18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0RkVF MkIzRDExM0ZDMDBBMzE2MkQ2MDYxNTJDMjk0MzAxRUEyQzQ5MxEcYXJzZW5AZ2Vu dG9vLm9yZwAKCRBSwpQwHqLEkyehAP9zgE4yhhamarjy/DIiyi5bhxC8+FXTkWLh iYhxu0rcIQEA+SbXhpvJP2GzQZ+joMfecTmKCGfHMSIcGbUnf4OEVgA= =0c44 -----END PGP SIGNATURE----- --=-=-=--