From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-relay-internal-1.canonical.com (smtp-relay-internal-1.canonical.com [185.125.188.123]) by sourceware.org (Postfix) with ESMTPS id 8C0F83858C20 for ; Mon, 31 Jan 2022 02:36:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8C0F83858C20 Received: from mail-ej1-f70.google.com (mail-ej1-f70.google.com [209.85.218.70]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp-relay-internal-1.canonical.com (Postfix) with ESMTPS id 97D833F1CA for ; Mon, 31 Jan 2022 02:36:12 +0000 (UTC) Received: by mail-ej1-f70.google.com with SMTP id fx12-20020a170906b74c00b006bbeab42f06so741751ejb.3 for ; Sun, 30 Jan 2022 18:36:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6htqoeFm8HBc/Q6bGQOD2LiuBlnmih2/pMiHzf+vGeU=; b=UNqWDQW9+YghR3Qrf8KWM2WjYvsqk9Mvx9NakQ5ThZDrQM3mDPxAsnp55c6I24DKXC 1Va369iVCeI5VsM6+aYNrVcUnUZ+Xoi0I6x2D2xxakRQil4Z/ebz4obVU1kglfJErsqz mkORok3y+V6NdViYqsKViie+HUiJ2DVPpw50uJs3SjwFwzgqITI7C7sQsmJEl2QPUN+J Vo7/RO2RfiTs9dr/GKdV+VWHiYlhn3WXIMLQSRlmSN3I+Vw1hObgu0y03gAOgkMjVLjj KJdKpd94iCq3+pj/hcyKm3jhDqxXyQgrnRJZc8ItWCwQ0q+iyqfivMMKVzMACMerN+bF 61vA== X-Gm-Message-State: AOAM533qFzRhJwjkppYHit5PARxl817S/r3xFTi221vtRNf/qgi6EvJe qtPY/HMVCxPV16SU7jT9428nJdJK4whCKPAnlVvimogUsXur1LciDKS2ImkTWy3sO1fmooT2mJJ OGmVMo4I1yj36Zz/yHipQQc4Tj4gYpbcX11WxmyiV1/K+Ms3WN9PIrA== X-Received: by 2002:a17:907:3e1e:: with SMTP id hp30mr15924182ejc.694.1643596571883; Sun, 30 Jan 2022 18:36:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJxQGMv5DddQ/0o9BQW2cR6gU0mNf2tmJhEV7w3RaZcpnZiWKGyJXwOPxFXYTx/rfqaGoSAdbWtNIT2D2XBYkmU= X-Received: by 2002:a17:907:3e1e:: with SMTP id hp30mr15924174ejc.694.1643596571650; Sun, 30 Jan 2022 18:36:11 -0800 (PST) MIME-Version: 1.0 References: <20220126214100.2433851-1-hjl.tools@gmail.com> In-Reply-To: <20220126214100.2433851-1-hjl.tools@gmail.com> From: Michael Hudson-Doyle Date: Mon, 31 Jan 2022 15:36:00 +1300 Message-ID: Subject: Re: [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment To: "H.J. Lu" Cc: libc-alpha@sourceware.org X-Spam-Status: No, score=-10.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, HTML_MESSAGE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Mon, 31 Jan 2022 02:36:15 -0000 On Thu, 27 Jan 2022 at 10:41, H.J. Lu via Libc-alpha < libc-alpha@sourceware.org> wrote: > tst-p_alignmod3.so has invalid p_align on LOAD segments which can't work > with GNU_RELRO. Pass -z norelro to linker to disable GNU_RELRO segment > to trigger > This helps for me on most Ubuntu architectures (s390x, arm64, ppc64el, probably armhf although that build hasn't finished yet) but I still see a failure on amd64 which still seems to hit the "cannot change memory protections" case (full log here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110381) and i386 (full log here: https://launchpad.net/~mwhudson/+archive/ubuntu/devirt/+build/23110384) where the loader seems to be segfaulting: (gdb) r Starting program: /build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/el= f/ld-linux.so.2 --library-path ../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-lib= c/elf:../build-tree/i386-libc/dlfcn:../build-tree/i386-libc/nss:../build-tr= ee/i386-libc/nis:../build-tree/i386-libc/rt:../build-tree/i386-libc/resolv:= ../build-tree/i386-libc/mathvec:../build-tree/i386-libc/support:../build-tr= ee/i386-libc/nptl ../build-tree/i386-libc/elf/tst-p_align3 Program received signal SIGSEGV, Segmentation fault. 0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120 120 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) (gdb) bt #0 0xf7fe9f08 in mprotect () at ../sysdeps/unix/syscall-template.S:120 #1 0xf7fcd299 in _dl_map_segments (loader=3D, has_holes=3Dt= rue, maplength=3D2044, nloadcmds=3D, loadcmds=3D0xffffc650, type= =3D3, header=3D, fd=3D3, l=3D0xf7fb7a70) at ./dl-map-segments.= h:116 #2 _dl_map_object_from_fd (name=3Dname@entry=3D0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/e= lf/tst-p_alignmod3.so", origname=3Dorigname@entry=3D0x0, fd=3D, fbp=3D, realname=3D, loader=3D, l_type=3D, mode=3D, stack_endp=3D, nsid=3D) at dl-load.c:1258 #3 0xf7fcebcd in _dl_map_object (loader=3D0xf7ffda70, name=3D0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/e= lf/tst-p_alignmod3.so", type=3D1, trace_mode=3D0, mode=3D0, nsid=3D) at dl-load.= c:2327 #4 0xf7fc8378 in openaux (a=3D0xffffcc98) at dl-deps.c:64 #5 0xf7fdf8c4 in _dl_catch_exception (exception=3D0xffffcc8c, operate=3D0xf7fc8340 , args=3D0xffffcc98) at dl-error-skeleton.c:2= 08 #6 0xf7fc87f0 in _dl_map_object_deps (map=3D, preloads=3D, npreloads=3D, trace_mode=3D, open_mode=3D) at dl-deps.c:248 #7 0xf7fe5bcf in dl_main (phdr=3D, phnum=3D, user_entry=3D, auxv=3D) at rtld.c:1969 #8 0xf7fe1c66 in _dl_sysdep_start (start_argptr=3D0xffffd440, dl_main=3D0xf7fe3ba0 ) at ../elf/dl-sysdep.c:256 #9 0xf7fe393f in _dl_start_final (arg=3D0xffffd440) at rtld.c:506 #10 _dl_start (arg=3D) at rtld.c:595 #11 0xf7fe273b in _start () from /build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/el= f/ld-linux.so.2 I think but am not sure that "loadcmds[nloadcmds - 1].mapstart" is 0 and "c->mapend" is 4096 so mprotect is getting called with an insane len in this code: if (__glibc_unlikely (__mprotect ((caddr_t) (l->l_addr + c->mapend), loadcmds[nloadcmds - 1].mapstart - c->mapend, PROT_NONE) < 0)) return DL_MAP_SEGMENTS_ERROR_MPROTECT; } but it's all pretty new to me. It's also possible that this is something about how Ubuntu's binutils is configured, I suppose. Cheers, mwh > .../elf/tst-p_alignmod3.so: ELF load command address/offset not > page-aligned > > instead of > > .../elf/tst-p_alignmod3.so: cannot change memory protections > --- > elf/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/elf/Makefile b/elf/Makefile > index daafb5cf12..6229add1fc 100644 > --- a/elf/Makefile > +++ b/elf/Makefile > @@ -2619,7 +2619,7 @@ $(objpfx)tst-p_alignmod2.so: > $(objpfx)tst-p_alignmod-base.so > cp $(objpfx)tst-p_alignmod-base.so $@ > $(PYTHON) $(..)scripts/tst-elf-edit.py -a 1 $@ > > -LDFLAGS-tst-p_alignmod3.so +=3D > -Wl,-z,max-page-size=3D0x100,-z,common-page-size=3D0x100 > +LDFLAGS-tst-p_alignmod3.so +=3D > -Wl,-z,max-page-size=3D0x100,-z,common-page-size=3D0x100,-z,norelro > > $(objpfx)tst-p_align3: $(objpfx)tst-p_alignmod3.so > $(objpfx)tst-p_align3.out: tst-p_align3.sh $(objpfx)tst-p_align3 > -- > 2.34.1 > >