* [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment @ 2022-01-26 21:41 H.J. Lu 2022-01-31 2:36 ` Michael Hudson-Doyle 0 siblings, 1 reply; 5+ messages in thread From: H.J. Lu @ 2022-01-26 21:41 UTC (permalink / raw) To: libc-alpha 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 .../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 += -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100 +LDFLAGS-tst-p_alignmod3.so += -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100,-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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment 2022-01-26 21:41 [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment H.J. Lu @ 2022-01-31 2:36 ` Michael Hudson-Doyle 2022-01-31 4:49 ` H.J. Lu 0 siblings, 1 reply; 5+ messages in thread From: Michael Hudson-Doyle @ 2022-01-31 2:36 UTC (permalink / raw) To: H.J. Lu; +Cc: libc-alpha 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/elf/ld-linux.so.2 --library-path ../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-libc/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/resolv:../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=<optimized out>, has_holes=true, maplength=2044, nloadcmds=<optimized out>, loadcmds=0xffffc650, type=3, header=<optimized out>, fd=3, l=0xf7fb7a70) at ./dl-map-segments.h:116 #2 _dl_map_object_from_fd (name=name@entry=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so", origname=origname@entry=0x0, fd=<optimized out>, fbp=<optimized out>, realname=<optimized out>, loader=<optimized out>, l_type=<optimized out>, mode=<optimized out>, stack_endp=<optimized out>, nsid=<optimized out>) at dl-load.c:1258 #3 0xf7fcebcd in _dl_map_object (loader=0xf7ffda70, name=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so", type=1, trace_mode=0, mode=0, nsid=<optimized out>) at dl-load.c:2327 #4 0xf7fc8378 in openaux (a=0xffffcc98) at dl-deps.c:64 #5 0xf7fdf8c4 in _dl_catch_exception (exception=0xffffcc8c, operate=0xf7fc8340 <openaux>, args=0xffffcc98) at dl-error-skeleton.c:208 #6 0xf7fc87f0 in _dl_map_object_deps (map=<optimized out>, preloads=<optimized out>, npreloads=<optimized out>, trace_mode=<optimized out>, open_mode=<optimized out>) at dl-deps.c:248 #7 0xf7fe5bcf in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1969 #8 0xf7fe1c66 in _dl_sysdep_start (start_argptr=0xffffd440, dl_main=0xf7fe3ba0 <dl_main>) at ../elf/dl-sysdep.c:256 #9 0xf7fe393f in _dl_start_final (arg=0xffffd440) at rtld.c:506 #10 _dl_start (arg=<optimized out>) 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 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 += > -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100 > +LDFLAGS-tst-p_alignmod3.so += > -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100,-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 > > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment 2022-01-31 2:36 ` Michael Hudson-Doyle @ 2022-01-31 4:49 ` H.J. Lu 2022-01-31 7:49 ` Michael Hudson-Doyle 0 siblings, 1 reply; 5+ messages in thread From: H.J. Lu @ 2022-01-31 4:49 UTC (permalink / raw) To: Michael Hudson-Doyle; +Cc: GNU C Library On Sun, Jan 30, 2022 at 6:36 PM Michael Hudson-Doyle <michael.hudson@canonical.com> 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 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/elf/ld-linux.so.2 --library-path ../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-libc/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/resolv:../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=<optimized out>, has_holes=true, maplength=2044, nloadcmds=<optimized out>, loadcmds=0xffffc650, type=3, > header=<optimized out>, fd=3, l=0xf7fb7a70) at ./dl-map-segments.h:116 > #2 _dl_map_object_from_fd (name=name@entry=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so", > origname=origname@entry=0x0, fd=<optimized out>, fbp=<optimized out>, realname=<optimized out>, loader=<optimized out>, l_type=<optimized out>, mode=<optimized out>, > stack_endp=<optimized out>, nsid=<optimized out>) at dl-load.c:1258 > #3 0xf7fcebcd in _dl_map_object (loader=0xf7ffda70, name=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so", > type=1, trace_mode=0, mode=0, nsid=<optimized out>) at dl-load.c:2327 > #4 0xf7fc8378 in openaux (a=0xffffcc98) at dl-deps.c:64 > #5 0xf7fdf8c4 in _dl_catch_exception (exception=0xffffcc8c, operate=0xf7fc8340 <openaux>, args=0xffffcc98) at dl-error-skeleton.c:208 > #6 0xf7fc87f0 in _dl_map_object_deps (map=<optimized out>, preloads=<optimized out>, npreloads=<optimized out>, trace_mode=<optimized out>, open_mode=<optimized out>) > at dl-deps.c:248 > #7 0xf7fe5bcf in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1969 > #8 0xf7fe1c66 in _dl_sysdep_start (start_argptr=0xffffd440, dl_main=0xf7fe3ba0 <dl_main>) at ../elf/dl-sysdep.c:256 > #9 0xf7fe393f in _dl_start_final (arg=0xffffd440) at rtld.c:506 > #10 _dl_start (arg=<optimized out>) 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 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. 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. > 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 += -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100 >> +LDFLAGS-tst-p_alignmod3.so += -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100,-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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment 2022-01-31 4:49 ` H.J. Lu @ 2022-01-31 7:49 ` Michael Hudson-Doyle 2022-01-31 15:26 ` H.J. Lu 0 siblings, 1 reply; 5+ messages in thread From: Michael Hudson-Doyle @ 2022-01-31 7:49 UTC (permalink / raw) To: H.J. Lu; +Cc: GNU C Library On Mon, 31 Jan 2022 at 17:49, H.J. Lu <hjl.tools@gmail.com> wrote: > On Sun, Jan 30, 2022 at 6:36 PM Michael Hudson-Doyle > <michael.hudson@canonical.com> 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 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/elf/ld-linux.so.2 > --library-path > ../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-libc/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/resolv:../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=<optimized out>, > has_holes=true, maplength=2044, nloadcmds=<optimized out>, > loadcmds=0xffffc650, type=3, > > header=<optimized out>, fd=3, l=0xf7fb7a70) at > ./dl-map-segments.h:116 > > #2 _dl_map_object_from_fd (name=name@entry=0xf7fb9b03 > "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so", > > origname=origname@entry=0x0, fd=<optimized out>, fbp=<optimized > out>, realname=<optimized out>, loader=<optimized out>, l_type=<optimized > out>, mode=<optimized out>, > > stack_endp=<optimized out>, nsid=<optimized out>) at dl-load.c:1258 > > #3 0xf7fcebcd in _dl_map_object (loader=0xf7ffda70, name=0xf7fb9b03 > "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so", > > type=1, trace_mode=0, mode=0, nsid=<optimized out>) at dl-load.c:2327 > > #4 0xf7fc8378 in openaux (a=0xffffcc98) at dl-deps.c:64 > > #5 0xf7fdf8c4 in _dl_catch_exception (exception=0xffffcc8c, > operate=0xf7fc8340 <openaux>, args=0xffffcc98) at dl-error-skeleton.c:208 > > #6 0xf7fc87f0 in _dl_map_object_deps (map=<optimized out>, > preloads=<optimized out>, npreloads=<optimized out>, trace_mode=<optimized > out>, open_mode=<optimized out>) > > at dl-deps.c:248 > > #7 0xf7fe5bcf in dl_main (phdr=<optimized out>, phnum=<optimized out>, > user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1969 > > #8 0xf7fe1c66 in _dl_sysdep_start (start_argptr=0xffffd440, > dl_main=0xf7fe3ba0 <dl_main>) at ../elf/dl-sysdep.c:256 > > #9 0xf7fe393f in _dl_start_final (arg=0xffffd440) at rtld.c:506 > > #10 _dl_start (arg=<optimized out>) 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 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. > > 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 += > -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100 > >> +LDFLAGS-tst-p_alignmod3.so += > -Wl,-z,max-page-size=0x100,-z,common-page-size=0x100,-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. > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment 2022-01-31 7:49 ` Michael Hudson-Doyle @ 2022-01-31 15:26 ` H.J. Lu 0 siblings, 0 replies; 5+ messages in thread From: H.J. Lu @ 2022-01-31 15:26 UTC (permalink / raw) To: Michael Hudson-Doyle; +Cc: GNU C Library On Sun, Jan 30, 2022 at 11:49 PM Michael Hudson-Doyle <michael.hudson@canonical.com> wrote: > > > > On Mon, 31 Jan 2022 at 17:49, H.J. Lu <hjl.tools@gmail.com> wrote: >> >> On Sun, Jan 30, 2022 at 6:36 PM Michael Hudson-Doyle >> <michael.hudson@canonical.com> 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 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/elf/ld-linux.so.2 --library-path ../build-tree/i386-libc:../build-tree/i386-libc/math:../build-tree/i386-libc/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/resolv:../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=<optimized out>, has_holes=true, maplength=2044, nloadcmds=<optimized out>, loadcmds=0xffffc650, type=3, >> > header=<optimized out>, fd=3, l=0xf7fb7a70) at ./dl-map-segments.h:116 >> > #2 _dl_map_object_from_fd (name=name@entry=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so", >> > origname=origname@entry=0x0, fd=<optimized out>, fbp=<optimized out>, realname=<optimized out>, loader=<optimized out>, l_type=<optimized out>, mode=<optimized out>, >> > stack_endp=<optimized out>, nsid=<optimized out>) at dl-load.c:1258 >> > #3 0xf7fcebcd in _dl_map_object (loader=0xf7ffda70, name=0xf7fb9b03 "/build/glibc-xBQSrs/glibc-2.34.9000-596-g4556b6edae/build-tree/i386-libc/elf/tst-p_alignmod3.so", >> > type=1, trace_mode=0, mode=0, nsid=<optimized out>) at dl-load.c:2327 >> > #4 0xf7fc8378 in openaux (a=0xffffcc98) at dl-deps.c:64 >> > #5 0xf7fdf8c4 in _dl_catch_exception (exception=0xffffcc8c, operate=0xf7fc8340 <openaux>, args=0xffffcc98) at dl-error-skeleton.c:208 >> > #6 0xf7fc87f0 in _dl_map_object_deps (map=<optimized out>, preloads=<optimized out>, npreloads=<optimized out>, trace_mode=<optimized out>, open_mode=<optimized out>) >> > at dl-deps.c:248 >> > #7 0xf7fe5bcf in dl_main (phdr=<optimized out>, phnum=<optimized out>, user_entry=<optimized out>, auxv=<optimized out>) at rtld.c:1969 >> > #8 0xf7fe1c66 in _dl_sysdep_start (start_argptr=0xffffd440, dl_main=0xf7fe3ba0 <dl_main>) at ../elf/dl-sysdep.c:256 >> > #9 0xf7fe393f in _dl_start_final (arg=0xffffd440) at rtld.c:506 >> > #10 _dl_start (arg=<optimized out>) 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 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. >> >> 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 -- H.J. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-01-31 15:26 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-26 21:41 [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment H.J. Lu 2022-01-31 2:36 ` Michael Hudson-Doyle 2022-01-31 4:49 ` H.J. Lu 2022-01-31 7:49 ` Michael Hudson-Doyle 2022-01-31 15:26 ` H.J. Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).