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 8D75B3858D28 for ; Mon, 31 Jan 2022 07:49:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8D75B3858D28 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 072073F1F6 for ; Mon, 31 Jan 2022 07:49:47 +0000 (UTC) Received: by mail-ej1-f70.google.com with SMTP id v2-20020a170906292200b006a94a27f903so4645887ejd.8 for ; Sun, 30 Jan 2022 23:49:47 -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=R8xfOVntMK/AckhGwY1ZqV6UUvVvIcDu5TxeUfkudvs=; b=4rA1Fd6UKwFxzkK+yiuHUgvcKkKVPKuctDVwiosBE3/lFh01jtMkYgeLDVnlsuXkNQ XDnVLJh/w647nl+h7DXZe2aK7xLrRK9Y91T54U51ZNElNAlNrYCmI0HZyDRKg5qER//8 9xjmRBINtWXUCdD7r2oe+CBgMrkbIwoLI9xktERlRQR+FEmjFtRcWovGVT5EBoYr4SJ4 xQYhFB3T5kxWeoxP7i4Rdgck3H0wJx1QxaCI0PvlMk3vgXviSYNsFg1lXGdW0mzLMk5P /zqO2x/VedqawrcvoAaYVphcM3lNmb4D/jOGPTBxiFJKMe/j8ByRXP74k3RX0oAAc/97 M/Hg== X-Gm-Message-State: AOAM531gaHt0ZBzZzIpVIt1WGCl8TgZ3gU7irJrmTWv/+N5LwgLe3bB/ kzR4VUB7AYoa7dJkurRo1piOZ3UCBJIA988jmabEwtN56BAwZg5T9ZjAMjyHPr7fSn8Q+uEqadm 2cn6N8o+sh1Et6jCTyQ1xIE3XOD+M5dicb3ZV/xQuz2cYgmPbKuMkkg== X-Received: by 2002:a05:6402:d0d:: with SMTP id eb13mr20185117edb.186.1643615386728; Sun, 30 Jan 2022 23:49:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJwHsU15ImNrDSc5jfpWiVm5BHGtElTkAaiFsiD9jPeMpS3fN8HgjVyEoXEjskiCrMCYGgDQGM7d5btn++JfDA0= X-Received: by 2002:a05:6402:d0d:: with SMTP id eb13mr20185108edb.186.1643615386495; Sun, 30 Jan 2022 23:49:46 -0800 (PST) MIME-Version: 1.0 References: <20220126214100.2433851-1-hjl.tools@gmail.com> In-Reply-To: From: Michael Hudson-Doyle Date: Mon, 31 Jan 2022 20:49:35 +1300 Message-ID: Subject: Re: [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment To: "H.J. Lu" Cc: GNU C Library X-Spam-Status: No, score=-10.8 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 07:49:50 -0000 On Mon, 31 Jan 2022 at 17:49, H.J. Lu wrote: > On Sun, Jan 30, 2022 at 6:36 PM Michael Hudson-Doyle > wrote: > > > > > > > > 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 wo= rk > >> with GNU_RELRO. Pass -z norelro to linker to disable GNU_RELRO segmen= t > >> 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/= elf/ld-linux.so.2 > --library-path > ../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-l= ibc/elf:../build-tree/i386-libc/dlfcn:../build-tree/i386-libc/nss:../build-= tree/i386-libc/nis:../build-tree/i386-libc/rt:../build-tree/i386-libc/resol= v:../build-tree/i386-libc/mathvec:../build-tree/i386-libc/support:../build-= tree/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=3Dtrue, 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= /elf/tst-p_alignmod3.so", > > origname=3Dorigname@entry=3D0x0, fd=3D, fbp=3D out>, realname=3D, loader=3D, l_type=3D out>, mode=3D, > > stack_endp=3D, nsid=3D) at dl-load.c:= 1258 > > #3 0xf7fcebcd in _dl_map_object (loader=3D0xf7ffda70, name=3D0xf7fb9b0= 3 > "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc= /elf/tst-p_alignmod3.so", > > type=3D1, trace_mode=3D0, mode=3D0, nsid=3D) at dl-l= oad.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= :208 > > #6 0xf7fc87f0 in _dl_map_object_deps (map=3D, > preloads=3D, npreloads=3D, trace_mode=3D out>, 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/= elf/ld-linux.so.2 > > > > I think but am not sure that "loadcmds[nloadcmds - 1].mapstart" is 0 an= d > "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 somethin= g > about how Ubuntu's binutils is configured, I suppose. > > tst-p_alignmod3.so is invalid and is very sensitive to how it is built. > But the loader shouldn't crash in any case. Please provide i386 and > x86-64 tst-p_alignmod3.so so that I can fix it. > I've uploaded them to https://people.canonical.com/~mwh/p_align3/ Cheers, mwh > > 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 > >> > > > -- > H.J. >