public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Michael Hudson-Doyle <michael.hudson@canonical.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH] tst-p_alignmod3.so: Disable GNU_RELRO segment
Date: Mon, 31 Jan 2022 15:36:00 +1300	[thread overview]
Message-ID: <CAJ8wqtcGSZVPxVHJWNXdp5yuvo5Ae2xCVhy2K0UZ17HVEDwqVw@mail.gmail.com> (raw)
In-Reply-To: <20220126214100.2433851-1-hjl.tools@gmail.com>

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
>
>

  reply	other threads:[~2022-01-31  2:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-26 21:41 H.J. Lu
2022-01-31  2:36 ` Michael Hudson-Doyle [this message]
2022-01-31  4:49   ` H.J. Lu
2022-01-31  7:49     ` Michael Hudson-Doyle
2022-01-31 15:26       ` H.J. Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAJ8wqtcGSZVPxVHJWNXdp5yuvo5Ae2xCVhy2K0UZ17HVEDwqVw@mail.gmail.com \
    --to=michael.hudson@canonical.com \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).