From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by sourceware.org (Postfix) with ESMTPS id 7621D3858402; Mon, 18 Oct 2021 17:28:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7621D3858402 Received: by mail-pj1-x102d.google.com with SMTP id oa12-20020a17090b1bcc00b0019f715462a8so513220pjb.3; Mon, 18 Oct 2021 10:28:55 -0700 (PDT) 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=0pfrAIhH4gGCFXq/GcBdfWU2eOfj62f8MzkARbXWQEI=; b=4jrXB/X8EekIUGJ1z+dKlcKnSkQQHsFJKdSl6iJNAjOB1Y1gL5ucys6r/DEduQXgSp I/pV0RCfGTvRQ/2EY14nIPG7sU50SdDSGYxtT04i9XUWvAEzl8EOh8ttx061sPQLteER BxFlSIzTq7XOIgS/i2Kyiffm95VrbAVjQ5YQaWNy6W2Z/t+U+nCPeXH6eBVsnS8HhDp3 40BZuBf721W/XWdxIUMgj+4hh63wUQdAGT6ZTow3MUhqK3PvIhW3eWdOxVJf9eHk/jau ykcNfN8/Evm8fnavViFMwsX6sJG29PSHVjOq6UUuIwN6qnXqzF3ITbXTXEOwSI6rAGsD whvQ== X-Gm-Message-State: AOAM530ZGzMqz24hcKyte+ZpZrGh5ao5pkQa/BCoQk9+RN5ghr6z/gZi n8ZMvd8F+49jlbt1SBqQNpsMvLJjv+v/wuU0ah0= X-Google-Smtp-Source: ABdhPJwvSWYlcaXy6NRkqT5N8O4Z5AdCShpBf5pK4l+YFsSJ5iE4iVGwwS6ONyHWJ4gcECsrtKfgLgMz5B+Hl/5TizY= X-Received: by 2002:a17:90a:c70d:: with SMTP id o13mr205579pjt.143.1634578134450; Mon, 18 Oct 2021 10:28:54 -0700 (PDT) MIME-Version: 1.0 References: <20211017005020.2645717-1-maskray@google.com> In-Reply-To: From: "H.J. Lu" Date: Mon, 18 Oct 2021 10:28:18 -0700 Message-ID: Subject: Re: [PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924] To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: GNU C Library , Binutils Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3029.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP 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, 18 Oct 2021 17:29:00 -0000 On Mon, Oct 18, 2021 at 9:17 AM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > On Mon, Oct 18, 2021 at 7:42 AM H.J. Lu wrote: > > > > On Sat, Oct 16, 2021 at 5:50 PM Fangrui Song via Binutils > > wrote: > > > > > > PIE and shared objects usually have many relative relocations. In > > > 2017/2018, SHT_RELR/DT_RELR was proposed on > > > https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/GxjM0L-PBAAJ > > > ("Proposal for a new section type SHT_RELR") and is a pre-standard. R= ELR > > > usually takes 3% or smaller space than R_*_RELATIVE relocations. The > > > virtual memory size of a mostly statically linked PIE is typically 5~= 10% > > > smaller. > > > > > > --- > > > > > > Notes I will not include in the submitted commit: > > > > > > Available on https://sourceware.org/git/?p=3Dglibc.git;a=3Dshortlog;h= =3Drefs/heads/maskray/relr > > > > > > "pre-standard": even Solaris folks are happy with the refined generic= -abi > > > proposal. Cary Coutant will apply the change > > > https://sourceware.org/pipermail/libc-alpha/2021-October/131781.html > > > > > > This patch is simpler than Chrome OS's glibc patch and makes ELF_DYNA= MIC_DO_RELR > > > available to all ports. I don't think the current glibc implementatio= n > > > supports ia64 in an ELFCLASS32 container. That said, the style I used= is > > > works with an ELFCLASS32 container for 64-bit machine if ElfW(Addr) i= s > > > 64-bit. > > > > > > * Chrome OS folks have carried a local patch since 2018 (latest versi= on: > > > https://chromium.googlesource.com/chromiumos/overlays/chromiumos-ov= erlay/+/refs/heads/main/sys-libs/glibc/files/local/glibc-2.32). > > > I.e. this feature has been battle tested. > > > * Android bionic supports 2018 and switched to DT_RELR=3D=3D36 in 202= 0. > > > * The Linux kernel has supported CONFIG_RELR since 2019-08 > > > (https://git.kernel.org/linus/5cf896fb6be3effd9aea455b22213e27be8bd= b1d). > > > * A musl patch (by me) exists but is not applied: > > > https://www.openwall.com/lists/musl/2019/03/06/3 > > > * rtld-elf from FreeBSD 14 will support DT_RELR. > > > > > > I believe upstream glibc should support DT_RELR to benefit all Linux > > > distributions. I filed some feature requests to get their attention: > > > > > > * Gentoo: https://bugs.gentoo.org/818376 > > > * Arch Linux: https://bugs.archlinux.org/task/72433 > > > * Debian https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D996598 > > > * Fedora https://bugzilla.redhat.com/show_bug.cgi?id=3D2014699 > > > > > > As of linker support (to the best of my knowledge): > > > > > > * LLD support DT_RELR. > > > * https://chromium.googlesource.com/chromiumos/overlays/chromiumos-ov= erlay/+/refs/heads/main/sys-devel/binutils/files/ > > > has a gold patch. > > > * GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi= ?id=3D27923 > > > > > > I wish that GNU ld and gold maintainers can implement the feature as = well :) > > > > > > Tested on aarch64 and x86_64. > > > > > > Changes from v1 (https://sourceware.org/pipermail/libc-alpha/2021-Oct= ober/131768.html) > > > * Fix style, simplify code > > > * Improve test > > > --- > > > configure | 31 +++++++++++++++++++++++++++++++ > > > configure.ac | 4 ++++ > > > elf/Makefile | 4 ++++ > > > elf/dynamic-link.h | 28 ++++++++++++++++++++++++++++ > > > elf/elf.h | 13 +++++++++++-- > > > elf/get-dynamic-info.h | 3 +++ > > > elf/tst-relr.c | 27 +++++++++++++++++++++++++++ > > > 7 files changed, 108 insertions(+), 2 deletions(-) > > > create mode 100644 elf/tst-relr.c > > > > > > diff --git a/configure b/configure > > > index 3227e434d3..fdab6a97ef 100755 > > > --- a/configure > > > +++ b/configure > > > @@ -6067,6 +6067,37 @@ $as_echo "$libc_linker_feature" >&6; } > > > config_vars=3D"$config_vars > > > have-depaudit =3D $libc_cv_depaudit" > > > > > > +{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for linker that su= pports --pack-dyn-relocs=3Drelr" >&5 > > > +$as_echo_n "checking for linker that supports --pack-dyn-relocs=3Dre= lr... " >&6; } > > > +libc_linker_feature=3Dno > > > +if test x"$gnu_ld" =3D x"yes"; then > > > + cat > conftest.c < > > +int _start (void) { return 42; } > > > +EOF > > > + if { ac_try=3D'${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS $no_ssp > > > + -Wl,--pack-dyn-relocs=3Drelr -nostdlib -nostartfi= les > > > + -fPIC -shared -o conftest.so conftest.c > > > + 1>&5' > > > + { { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >= &5 > > > + (eval $ac_try) 2>&5 > > > + ac_status=3D$? > > > + $as_echo "$as_me:${as_lineno-$LINENO}: \$? =3D $ac_status" >&5 > > > + test $ac_status =3D 0; }; } > > > + then > > > + libc_linker_feature=3Dyes > > > + fi > > > + rm -f conftest* > > > +fi > > > +if test $libc_linker_feature =3D yes; then > > > + libc_cv_relr=3Dyes > > > +else > > > + libc_cv_relr=3Dno > > > +fi > > > +{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $libc_linker_featur= e" >&5 > > > +$as_echo "$libc_linker_feature" >&6; } > > > +config_vars=3D"$config_vars > > > +have-relr =3D $libc_cv_relr" > > > + > > > { $as_echo "$as_me:${as_lineno-$LINENO}: checking for linker that su= pports --no-dynamic-linker" >&5 > > > $as_echo_n "checking for linker that supports --no-dynamic-linker...= " >&6; } > > > libc_linker_feature=3Dno > > > diff --git a/configure.ac b/configure.ac > > > index 00f49f09f7..96110f9d7d 100644 > > > --- a/configure.ac > > > +++ b/configure.ac > > > @@ -1354,6 +1354,10 @@ LIBC_LINKER_FEATURE([--depaudit], [-Wl,--depau= dit,x], > > > [libc_cv_depaudit=3Dyes], [libc_cv_depaudit=3Dno]= ) > > > LIBC_CONFIG_VAR([have-depaudit], [$libc_cv_depaudit]) > > > > > > +LIBC_LINKER_FEATURE([--pack-dyn-relocs=3Drelr], [-Wl,--pack-dyn-relo= cs=3Drelr], > > > + [libc_cv_relr=3Dyes], [libc_cv_relr=3Dno]) > > > +LIBC_CONFIG_VAR([have-relr], [$libc_cv_relr]) > > > + > > > LIBC_LINKER_FEATURE([--no-dynamic-linker], > > > [-Wl,--no-dynamic-linker], > > > [libc_cv_no_dynamic_linker=3Dyes], > > > diff --git a/elf/Makefile b/elf/Makefile > > > index bf45d8ee24..2c4cdfac68 100644 > > > --- a/elf/Makefile > > > +++ b/elf/Makefile > > > @@ -245,6 +245,10 @@ tests-special +=3D $(objpfx)tst-audit14-cmp.out = $(objpfx)tst-audit15-cmp.out \ > > > $(objpfx)tst-audit16-cmp.out > > > endif > > > endif > > > +ifeq ($(have-relr),yes) > > > +tests +=3D tst-relr > > > +LDFLAGS-tst-relr +=3D -Wl,--pack-dyn-relocs=3Drelr > > > +endif > > > endif > > > > Is DT_RELR only generated for PIE? If yes, you need to add it > > to tests-pie and compile it as PIE. > > PIE and shared objects. PDE doesn't need relative relocations. > It is useful to ensure that -Wl,--pack-dyn-relocs=3Drelr doesn't cause > breakage to PDE. Then you need to add a PIE test to verify that 1. It has DT_RELR. 2. It runs correctly. > > [hjl@gnu-cfl-2 tmp]$ gcc -pie -fPIE -O2 tst-relr.c > > -Wl,--pack-dyn-relocs=3Drelr -fuse-ld=3Dlld > > [hjl@gnu-cfl-2 tmp]$ ./a.out > > Segmentation fault (core dumped) > > [hjl@gnu-cfl-2 tmp]$ > > > > Given that the current lld implementation generates broken > > binaries for existing glibc without any warning at run-time, > > we should use a different linker command line option to > > implement it properly so that the new binary will fail to > > run on glibc without DT_RELR support at run-time. > > I don't think so. LLD's design is to be machine agnostic and NOT make > decisions which would vary on different machines. > --pack-dyn-relocs=3Drelr is not the default. The user tells LLD to use > DT_RELR and the user is responsible for making sure target ld.so > supports DT_RELR. > LLD is often used as a cross linker. The host ld.so doesn't support > LLD doesn't mean that LLD should disable the format. > For example, it is totally fine to link a FreeBSD executable on a Linux m= achine. For Linux targets, we need the glibc version dependency for DT_RELR support at run-time. --=20 H.J.