[PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE

[Nick Desaulniers]

On Tue, Oct 20, 2020 at 10:57 AM Will Deacon <will at kernel.org> wrote:
>
> On Fri, 16 Oct 2020 10:53:39 -0700, Nick Desaulniers wrote:
> > With CONFIG_EXPERT=y, CONFIG_KASAN=y, CONFIG_RANDOMIZE_BASE=n,
> > CONFIG_RELOCATABLE=n, we observe the following failure when trying to
> > link the kernel image with LD=ld.lld:
> >
> > error: section: .exit.data is not contiguous with other relro sections
> >
> > ld.lld defaults to -z relro while ld.bfd defaults to -z norelro. This
> > was previously fixed, but only for CONFIG_RELOCATABLE=y.
>
> Applied to arm64 (for-next/core), thanks!
>
> [1/1] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
>       https://git.kernel.org/arm64/c/3b92fa7485eb

It looks like this is now producing warnings when linking with BFD.
$ make ...
...
  LD      .tmp_vmlinux.kallsyms1
aarch64-linux-gnu-ld: warning: -z norelro ignored
  KSYMS   .tmp_vmlinux.kallsyms1.S
  AS      .tmp_vmlinux.kallsyms1.S
  LD      .tmp_vmlinux.kallsyms2
aarch64-linux-gnu-ld: warning: -z norelro ignored
  KSYMS   .tmp_vmlinux.kallsyms2.S
  AS      .tmp_vmlinux.kallsyms2.S
  LD      vmlinux
aarch64-linux-gnu-ld: warning: -z norelro ignored

Alan, looking at binutils-gdb commit 5fd104addfddb ("Emit a warning
when -z relro is unsupported") mentions targets lacking relro support
will produce this warning.  I thought aarch64 supports relro
though...?
Looks like we're invoking:
+ aarch64-linux-gnu-ld -EL -maarch64elf --no-undefined -X -z norelro
-shared -Bsymbolic -z notext --no-apply-dynamic-relocs
--fix-cortex-a53-843419 --build-id=sha1 --orphan-handling=warn
--strip-debug -o .tmp_vmlinux.kallsyms1 -T
./arch/arm64/kernel/vmlinux.lds --whole-archive
arch/arm64/kernel/head.o init/built-in.a usr/built-in.a
arch/arm64/built-in.a kernel/built-in.a certs/built-in.a mm/built-in.a
fs/built-in.a ipc/built-in.a security/built-in.a crypto/built-in.a
block/built-in.a arch/arm64/lib/built-in.a lib/built-in.a
arch/arm64/lib/lib.a lib/lib.a drivers/built-in.a sound/built-in.a
net/built-in.a virt/built-in.a --no-whole-archive --start-group
./drivers/firmware/efi/libstub/lib.a --end-group
aarch64-linux-gnu-ld: warning: -z norelro ignored

So we set the emulation mode via -maarch64elf, and our preprocessed
linker script has `OUTPUT_ARCH(aarch64)`. From that commit, there's a
linked mailing list discussion:
https://sourceware.org/legacy-ml/binutils/2017-01/msg00441.html

Is there something more we need to do to our linker script
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/kernel/vmlinux.lds.S)
for BFD not to warn when passing `-z norelro`?  It looks like common
page size might need to be specified?  I tried:

diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 1bda604f4c70..ae8cce140fdf 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -121,7 +121,7 @@ SECTIONS
                _text = .;
                HEAD_TEXT
        }
-       .text : {                       /* Real text segment            */
+       .text ALIGN (CONSTANT (COMMONPAGESIZE)): {      /* Real text
segment    */

and passing `-z common-page-size=4096` but neither seemed to do the
trick. (https://docs.adacore.com/live/wave/binutils-stable/html/ld/ld.html#index-COMMONPAGESIZE-553

Worst case, we add `-z norelro` just for LLD:

diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 6a87d592bd00..6a6235e1e8a9 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
@@ -28,6 +28,10 @@ LDFLAGS_vmlinux      += --fix-cortex-a53-843419
   endif
 endif

+ifeq ($(CONFIG_LD_IS_LLD), y)
+LDFLAGS_vmlinux        += -z norelro
+endif
+
 ifeq ($(CONFIG_ARM64_USE_LSE_ATOMICS), y)
   ifneq ($(CONFIG_ARM64_LSE_ATOMICS), y)
 $(warning LSE atomics not supported by binutils)

-- 
Thanks,
~Nick Desaulniers