| Message ID | 20201217004051.1247544-1-ndesaulniers@google.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | arm64: link with -z norelro for LLD or aarch64-elf | expand |
On Wed, Dec 16, 2020 at 04:40:51PM -0800, Nick Desaulniers wrote: > With newer GNU binutils, linking with BFD produces warnings for vmlinux: > aarch64-linux-gnu-ld: warning: -z norelro ignored > > BFD can produce this warning when the target emulation mode does not > support RELRO relocation types, and -z relro or -z norelro is passed. > > Alan Modra clarifies: > The default linker emulation for an aarch64-linux ld.bfd is > -maarch64linux, the default for an aarch64-elf linker is > -maarch64elf. They are not equivalent. If you choose -maarch64elf > you get an emulation that doesn't support -z relro. > > The ARCH=arm64 kernel prefers -maarch64elf, but may fall back to > -maarch64linux based on the toolchain configuration. > > LLD will always create RELRO relocation types regardless of target > emulation. > > To avoid the above warning when linking with BFD, pass -z norelro only > when linking with LLD or with -maarch64linux. Given that, prior to 3b92fa7485eb, we used to pass '-z norelro' if CONFIG_RELOCATABLE then was this already broken with the ELF toolchain? Will
On Thu, 17 Dec 2020 at 01:41, Nick Desaulniers <ndesaulniers@google.com> wrote: > > With newer GNU binutils, linking with BFD produces warnings for vmlinux: > aarch64-linux-gnu-ld: warning: -z norelro ignored > > BFD can produce this warning when the target emulation mode does not > support RELRO relocation types, and -z relro or -z norelro is passed. > RELRO is not a relocation type, it is a type of program header which we might simply ignore, if it weren't for the fact that it can only be emitted if the layout of the sections adheres to certain rules (and ours doesn't), and we get an error otherwise. It amounts to implicit __ro_after_init annotations for statically initialized const pointers, but given that we don't compile with -fpie, those const pointers reside in .rodata already, so RELRO adds no value for us. > Alan Modra clarifies: > The default linker emulation for an aarch64-linux ld.bfd is > -maarch64linux, the default for an aarch64-elf linker is > -maarch64elf. They are not equivalent. If you choose -maarch64elf > you get an emulation that doesn't support -z relro. > > The ARCH=arm64 kernel prefers -maarch64elf, but may fall back to > -maarch64linux based on the toolchain configuration. > > LLD will always create RELRO relocation types regardless of target > emulation. > RELRO program header > To avoid the above warning when linking with BFD, pass -z norelro only > when linking with LLD or with -maarch64linux. > > Cc: Alan Modra <amodra@gmail.com> > Cc: Ard Biesheuvel <ardb@kernel.org> > Cc: Fāng-ruì Sòng <maskray@google.com> > Fixes: 3b92fa7485eb ("arm64: link with -z norelro regardless of CONFIG_RELOCATABLE") > Reported-by: kernelci.org bot <bot@kernelci.org> > Reported-by: Quentin Perret <qperret@google.com> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> With mentions of 'RELRO relocation types' fixed: Acked-by: Ard Biesheuvel <ardb@kernel.org> > --- > arch/arm64/Makefile | 10 +++++++--- > 1 file changed, 7 insertions(+), 3 deletions(-) > > diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile > index 6be9b3750250..90309208bb28 100644 > --- a/arch/arm64/Makefile > +++ b/arch/arm64/Makefile > @@ -10,7 +10,7 @@ > # > # Copyright (C) 1995-2001 by Russell King > > -LDFLAGS_vmlinux :=--no-undefined -X -z norelro > +LDFLAGS_vmlinux :=--no-undefined -X > > ifeq ($(CONFIG_RELOCATABLE), y) > # Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour > @@ -115,16 +115,20 @@ KBUILD_CPPFLAGS += -mbig-endian > CHECKFLAGS += -D__AARCH64EB__ > # Prefer the baremetal ELF build target, but not all toolchains include > # it so fall back to the standard linux version if needed. > -KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb) > +KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb -z norelro) > UTS_MACHINE := aarch64_be > else > KBUILD_CPPFLAGS += -mlittle-endian > CHECKFLAGS += -D__AARCH64EL__ > # Same as above, prefer ELF but fall back to linux target if needed. > -KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux) > +KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux -z norelro) > UTS_MACHINE := aarch64 > endif > > +ifeq ($(CONFIG_LD_IS_LLD), y) > +KBUILD_LDFLAGS += -z norelro > +endif > + > CHECKFLAGS += -D__aarch64__ > > ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y) > -- > 2.29.2.684.gfbc64c5ab5-goog >
On Thu, Dec 17, 2020 at 4:01 AM Will Deacon <will@kernel.org> wrote: > > On Wed, Dec 16, 2020 at 04:40:51PM -0800, Nick Desaulniers wrote: > > With newer GNU binutils, linking with BFD produces warnings for vmlinux: > > aarch64-linux-gnu-ld: warning: -z norelro ignored > > > Given that, prior to 3b92fa7485eb, we used to pass '-z norelro' if > CONFIG_RELOCATABLE then was this already broken with the ELF toolchain? Yes, though it would have been hard to foresee the change to BFD ~6 months later. Specifically, binutils-gdb commit 5fd104addfddb ("Emit a warning when -z relro is unsupported") was committed Fri Jun 19 09:50:20 2020 +0930. The first git tag that describes this commit was binutils-2_35 which was tagged Fri Jul 24 11:05:23 2020 +0100. I noticed about a month ago that the version of binutils-aarch64-linux-gnu installed on my gLinux workstation had auto updated to version 2.35.1; I was authoring kernel patches for DWARF v5 support, which relied on 2.35 for DWARF v5 assembler support. I suspect Quentin's host was auto updated as well, at which point he noticed and mentioned to me since I had touched `-z norelro` last. But if we look at commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker script and options") which was committed at Tue Dec 4 12:48:25 2018 +0000, it was not possible to foresee that binutils-gdb would change to produce such a warning for such an emulation mode. So I'm not sure whether my patch should either: - have a fixes tag for just the latest commit that touched anything related to `-z norelro`, mine, 3b92fa7485eb. - have an additional fixes tag for 3bbd3db86470 which first introduced `-z norelro`. - have no fixes tag I'll respin a v2 folding in Ard's suggestions. Meanwhile, I've filed: - https://bugs.llvm.org/show_bug.cgi?id=48549 against LLD - https://sourceware.org/bugzilla/show_bug.cgi?id=27093 against BFD -- Thanks, ~Nick Desaulniers
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 6be9b3750250..90309208bb28 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -10,7 +10,7 @@ # # Copyright (C) 1995-2001 by Russell King -LDFLAGS_vmlinux :=--no-undefined -X -z norelro +LDFLAGS_vmlinux :=--no-undefined -X ifeq ($(CONFIG_RELOCATABLE), y) # Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour @@ -115,16 +115,20 @@ KBUILD_CPPFLAGS += -mbig-endian CHECKFLAGS += -D__AARCH64EB__ # Prefer the baremetal ELF build target, but not all toolchains include # it so fall back to the standard linux version if needed. -KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb) +KBUILD_LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb -z norelro) UTS_MACHINE := aarch64_be else KBUILD_CPPFLAGS += -mlittle-endian CHECKFLAGS += -D__AARCH64EL__ # Same as above, prefer ELF but fall back to linux target if needed. -KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux) +KBUILD_LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux -z norelro) UTS_MACHINE := aarch64 endif +ifeq ($(CONFIG_LD_IS_LLD), y) +KBUILD_LDFLAGS += -z norelro +endif + CHECKFLAGS += -D__aarch64__ ifeq ($(CONFIG_DYNAMIC_FTRACE_WITH_REGS),y)
With newer GNU binutils, linking with BFD produces warnings for vmlinux: aarch64-linux-gnu-ld: warning: -z norelro ignored BFD can produce this warning when the target emulation mode does not support RELRO relocation types, and -z relro or -z norelro is passed. Alan Modra clarifies: The default linker emulation for an aarch64-linux ld.bfd is -maarch64linux, the default for an aarch64-elf linker is -maarch64elf. They are not equivalent. If you choose -maarch64elf you get an emulation that doesn't support -z relro. The ARCH=arm64 kernel prefers -maarch64elf, but may fall back to -maarch64linux based on the toolchain configuration. LLD will always create RELRO relocation types regardless of target emulation. To avoid the above warning when linking with BFD, pass -z norelro only when linking with LLD or with -maarch64linux. Cc: Alan Modra <amodra@gmail.com> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Fāng-ruì Sòng <maskray@google.com> Fixes: 3b92fa7485eb ("arm64: link with -z norelro regardless of CONFIG_RELOCATABLE") Reported-by: kernelci.org bot <bot@kernelci.org> Reported-by: Quentin Perret <qperret@google.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> --- arch/arm64/Makefile | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) -- 2.29.2.684.gfbc64c5ab5-goog