From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id D00D038515D7 for ; Mon, 31 Jan 2022 15:26:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D00D038515D7 Received: by mail-pj1-x1036.google.com with SMTP id d5so14317497pjk.5 for ; Mon, 31 Jan 2022 07:26:58 -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:content-transfer-encoding; bh=wByQS+xqck8MpMQLr70xFdsdma/GRgrhu8SWVqGo+mA=; b=NsWRDXM+WqcNwoz0QeBs2gt5W0C7jDy7C8aismQ+7qUt3wItqp/WBVv8Wu/3V1DuKM g723gQxqJNo4K/9JP3ocFuZGLqN31JIenh87wPCaBEgu6jMTxIJg+ySER86Awe8KE57I 5pIj04WCteURMJHYjSgMNn39M1K07u2h73GtCYPwlW5m589wOSmzlcZxtroqeTlDQULf 8qmKIwV4X7bkgoNbFeXJaeut/2pMuiN9PtUUfFHCDe3ruqWyz4y618OsyWMCk2kxg47M S2zlwKaJ4LcGCwm6vp4S69sLUFcxAiFRF2zWirmF7079oJuuDmQoveS+9G5DYAz0ZNMv L+jA== X-Gm-Message-State: AOAM531+MUbjRFemGf3RAUCtbSF6D/rPflsvYVdJwXjAssYyZz0s6NfP MIego/eB613IjtiQWUx/Ykcp90BxCq6xR5tUWpE= X-Google-Smtp-Source: ABdhPJzqU5hzrzL5BjhuiJwfl5VJFUIFZ6jCtp/zjTKIOq46CIKZn07fy2T9TJdBBhb0OTFGpRIozwCVLIxkCZ1Y2uE= X-Received: by 2002:a17:903:2350:: with SMTP id c16mr21592019plh.4.1643642817822; Mon, 31 Jan 2022 07:26:57 -0800 (PST) MIME-Version: 1.0 References: <20220126214100.2433851-1-hjl.tools@gmail.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 31 Jan 2022 07:26:22 -0800 Message-ID: Subject: Re: [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment To: Michael Hudson-Doyle Cc: GNU C Library Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3021.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, 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 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 15:27:00 -0000 On Sun, Jan 30, 2022 at 11:49 PM Michael Hudson-Doyle wrote: > > > > 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 wrote: >> >> >> >> tst-p_alignmod3.so has invalid p_align on LOAD segments which can't w= ork >> >> with GNU_RELRO. Pass -z norelro to linker to disable GNU_RELRO segme= nt >> >> 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 protect= ions" case (full log here: https://launchpad.net/~mwhudson/+archive/ubuntu/= devirt/+build/23110381) and i386 (full log here: https://launchpad.net/~mwh= udson/+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-li= bc:../build-tree/i386-libc/math:../build-tree/i386-libc/elf:../build-tree/i= 386-libc/dlfcn:../build-tree/i386-libc/nss:../build-tree/i386-libc/nis:../b= uild-tree/i386-libc/rt:../build-tree/i386-libc/resolv:../build-tree/i386-li= bc/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:12= 0 >> > #1 0xf7fcd299 in _dl_map_segments (loader=3D, has_hole= s=3Dtrue, maplength=3D2044, nloadcmds=3D, loadcmds=3D0xffffc= 650, type=3D3, >> > header=3D, fd=3D3, l=3D0xf7fb7a70) at ./dl-map-segm= ents.h:116 >> > #2 _dl_map_object_from_fd (name=3Dname@entry=3D0xf7fb9b03 "/build/gli= bc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_al= ignmod3.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=3D0xf7fb9b= 03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-lib= c/elf/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:208 >> > #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-5= 96-g4556b6edae/build-tree/i386-libc/elf/ld-linux.so.2 >> > >> > I think but am not sure that "loadcmds[nloadcmds - 1].mapstart" is 0 a= nd "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->mapen= d, >> > PROT_NONE) < 0)) >> > return DL_MAP_SEGMENTS_ERROR_MPROTECT; >> > } >> > >> > but it's all pretty new to me. It's also possible that this is somethi= ng 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/ > A patch is posted at https://sourceware.org/pipermail/libc-alpha/2022-January/135905.html --=20 H.J.