* [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
@ 2020-10-16 17:53 Nick Desaulniers
2020-10-20 17:57 ` Will Deacon
0 siblings, 1 reply; 14+ messages in thread
From: Nick Desaulniers @ 2020-10-16 17:53 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Ard Biesheuvel, Peter Smith, Fāng-ruì Sòng,
clang-built-linux, Nick Desaulniers, stable, linux-arm-kernel,
linux-kernel
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.
Cc: stable@vger.kernel.org
Fixes: commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker script and options")
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
While upgrading our toolchains for Android, we started seeing the above
failure for a particular config that enabled KASAN but disabled KASLR.
This was on a 5.4 stable branch. It looks like
commit dd4bc6076587 ("arm64: warn on incorrect placement of the kernel by the bootloader")
made RELOCATABLE=y the default and depend on EXPERT=y. With those two
enabled, we can then reproduce the same failure on mainline.
arch/arm64/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index f4717facf31e..674241df91ab 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -10,13 +10,13 @@
#
# Copyright (C) 1995-2001 by Russell King
-LDFLAGS_vmlinux :=--no-undefined -X
+LDFLAGS_vmlinux :=--no-undefined -X -z norelro
ifeq ($(CONFIG_RELOCATABLE), y)
# Pass --no-apply-dynamic-relocs to restore pre-binutils-2.27 behaviour
# for relative relocs, since this leads to better Image compression
# with the relocation offsets always being zero.
-LDFLAGS_vmlinux += -shared -Bsymbolic -z notext -z norelro \
+LDFLAGS_vmlinux += -shared -Bsymbolic -z notext \
$(call ld-option, --no-apply-dynamic-relocs)
endif
--
2.29.0.rc1.297.gfa9743e501-goog
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
2020-10-16 17:53 [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE Nick Desaulniers
@ 2020-10-20 17:57 ` Will Deacon
2020-10-20 20:16 ` Nick Desaulniers
2020-12-14 21:44 ` Nick Desaulniers
0 siblings, 2 replies; 14+ messages in thread
From: Will Deacon @ 2020-10-20 17:57 UTC (permalink / raw)
To: Catalin Marinas, Nick Desaulniers
Cc: kernel-team, Will Deacon, linux-kernel, Peter Smith,
clang-built-linux, stable, linux-arm-kernel, Ard Biesheuvel,
Fāng-ruì Sòng
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
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
2020-10-20 17:57 ` Will Deacon
@ 2020-10-20 20:16 ` Nick Desaulniers
2020-10-21 6:58 ` Ard Biesheuvel
2020-12-14 21:44 ` Nick Desaulniers
1 sibling, 1 reply; 14+ messages in thread
From: Nick Desaulniers @ 2020-10-20 20:16 UTC (permalink / raw)
To: Will Deacon, Ard Biesheuvel, Fāng-ruì Sòng,
Kees Cook, Dmitry Vyukov, Peter Oberparleiter
Cc: Catalin Marinas, kernel-team, LKML, Peter Smith,
clang-built-linux, # 3.4.x, Linux ARM, Arnd Bergmann
On Tue, Oct 20, 2020 at 10:57 AM Will Deacon <will@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
IF we wanted to go further and remove `-z norelro`, or even enable `-z
relro` for aarch64, then we would have to detangle some KASAN/GCOV
generated section discard spaghetti. Fangrui did some more digging
and found that .fini_array.* sections were relro (read only after
relocations, IIUC), so adding them to EXIT_DATA
(include/asm-generic/vmlinux.lds.h) was causing them to get included
in .exit.data (arch/arm64/kernel/vmlinux.lds.S) making that relro.
There's some history here with commits:
- e41f501d39126 ("vmlinux.lds: account for destructor sections")
- 8dcf86caa1e3da ("vmlinux.lds.h: Fix incomplete .text.exit discards")
- d812db78288d7 ("vmlinux.lds.h: Avoid KASAN and KCSAN's unwanted sections")
It seems the following works for quite a few different
configs/toolchains I played with, but the big IF is whether enabling
`-z relro` is worthwhile? If the kernel does respect that mapping,
then I assume that's a yes, but I haven't checked yet whether relro is
respected within the kernel (`grep -rn RELRO` turns up nothing
interesting). I also haven't checked yet whether all supported
versions of GNU ld.bfd support -z relro (guessing not, since a quick
test warns: `aarch64-linux-gnu-ld: warning: -z relro ignored` for
v2.34.90.20200706, may be holding it wrong).
(Fangrui also filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97507
in regards to GCOV+GCC)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index cd14444bf600..64578c998e53 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -744,7 +744,6 @@
#define EXIT_DATA \
*(.exit.data .exit.data.*) \
- *(.fini_array .fini_array.*) \
*(.dtors .dtors.*) \
MEM_DISCARD(exit.data*) \
MEM_DISCARD(exit.rodata*)
@@ -995,6 +994,7 @@
#if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN)
# ifdef CONFIG_CONSTRUCTORS
# define SANITIZER_DISCARDS \
+ *(.fini_array .fini_array.*) \
*(.eh_frame)
# else
# define SANITIZER_DISCARDS \
@@ -1005,8 +1005,16 @@
# define SANITIZER_DISCARDS
#endif
+#if defined(CONFIG_GCOV_KERNEL) && defined(CONFIG_CC_IS_GCC)
+# define GCOV_DISCARDS \
+ *(.fini_array .fini_array.*)
+#else
+# define GCOV_DISCARDS
+#endif
+
#define COMMON_DISCARDS
\
SANITIZER_DISCARDS \
+ GCOV_DISCARDS \
*(.discard) \
*(.discard.*) \
*(.modinfo) \
--
Thanks,
~Nick Desaulniers
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
2020-10-20 20:16 ` Nick Desaulniers
@ 2020-10-21 6:58 ` Ard Biesheuvel
0 siblings, 0 replies; 14+ messages in thread
From: Ard Biesheuvel @ 2020-10-21 6:58 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Will Deacon, Fāng-ruì Sòng, Kees Cook,
Dmitry Vyukov, Peter Oberparleiter, Catalin Marinas, kernel-team,
LKML, Peter Smith, clang-built-linux, # 3.4.x, Linux ARM,
Arnd Bergmann
On Tue, 20 Oct 2020 at 22:16, Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Tue, Oct 20, 2020 at 10:57 AM Will Deacon <will@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
>
> IF we wanted to go further and remove `-z norelro`, or even enable `-z
> relro` for aarch64, then we would have to detangle some KASAN/GCOV
> generated section discard spaghetti.
Why on earth would we want that?
> Fangrui did some more digging
> and found that .fini_array.* sections were relro (read only after
> relocations, IIUC), so adding them to EXIT_DATA
> (include/asm-generic/vmlinux.lds.h) was causing them to get included
> in .exit.data (arch/arm64/kernel/vmlinux.lds.S) making that relro.
> There's some history here with commits:
>
> - e41f501d39126 ("vmlinux.lds: account for destructor sections")
> - 8dcf86caa1e3da ("vmlinux.lds.h: Fix incomplete .text.exit discards")
> - d812db78288d7 ("vmlinux.lds.h: Avoid KASAN and KCSAN's unwanted sections")
>
> It seems the following works for quite a few different
> configs/toolchains I played with, but the big IF is whether enabling
> `-z relro` is worthwhile? If the kernel does respect that mapping,
> then I assume that's a yes, but I haven't checked yet whether relro is
> respected within the kernel (`grep -rn RELRO` turns up nothing
> interesting). I also haven't checked yet whether all supported
> versions of GNU ld.bfd support -z relro (guessing not, since a quick
> test warns: `aarch64-linux-gnu-ld: warning: -z relro ignored` for
> v2.34.90.20200706, may be holding it wrong).
>
RELRO just moves statically initialized const pointers into a separate
section so we can place it in a way that allows us to easily map it
r/w during load, and switch it over to r/o once the relocations have
been applied.
On AArch64, we don't even use -fpic to build the kernel, and load time
relocations may appear everywhere in .text, .rodata etc etc, which is
absolutely fine given that we apply the relocations way before we
finalize the kernel mappings. This means that, in our case, statically
initialized const pointers will be mapped r/o already, and we don't
need RELRO.
In general, we should ensure that the 'relocatable bare metal' case
doesn't get snowed under, as toolchain development is [understandably]
very focused on hosted binaries that use shared libraries, where
things like CoW footprint, ELF symbol preemption, text relocations and
RELRO sections actually matter. For bare metal, it is quite the
opposite: text relocations are fine, there is no CoW so minimizing the
footprint of the .so pages that are modified due to relocations is
unnecessary, and symbols cannot be preempted either. So many of the
shared library tricks actually make things worse for us, because we
have to work around them while they have no benefit for us.
I have suggested this before, but perhaps we should have a
-mcmodel=kernel (like x86 does) that takes these things into account?
As a start, it could imply -cmodel=small (which we rely on today), but
with guarantees that the generated code is position independent, but
without GOT indirections, and that the resulting object code can be
linked with -pie (so that we have access to the load time relocations
in the bare metal binary itself). This is something we rely on today,
and happens to work in practice, but this could easily break in the
future.
> (Fangrui also filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97507
> in regards to GCOV+GCC)
>
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index cd14444bf600..64578c998e53 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -744,7 +744,6 @@
>
> #define EXIT_DATA \
> *(.exit.data .exit.data.*) \
> - *(.fini_array .fini_array.*) \
> *(.dtors .dtors.*) \
> MEM_DISCARD(exit.data*) \
> MEM_DISCARD(exit.rodata*)
> @@ -995,6 +994,7 @@
> #if defined(CONFIG_KASAN_GENERIC) || defined(CONFIG_KCSAN)
> # ifdef CONFIG_CONSTRUCTORS
> # define SANITIZER_DISCARDS \
> + *(.fini_array .fini_array.*) \
> *(.eh_frame)
> # else
> # define SANITIZER_DISCARDS \
> @@ -1005,8 +1005,16 @@
> # define SANITIZER_DISCARDS
> #endif
>
> +#if defined(CONFIG_GCOV_KERNEL) && defined(CONFIG_CC_IS_GCC)
> +# define GCOV_DISCARDS \
> + *(.fini_array .fini_array.*)
> +#else
> +# define GCOV_DISCARDS
> +#endif
> +
> #define COMMON_DISCARDS
> \
> SANITIZER_DISCARDS \
> + GCOV_DISCARDS \
> *(.discard) \
> *(.discard.*) \
> *(.modinfo) \
> --
> Thanks,
> ~Nick Desaulniers
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
2020-10-20 17:57 ` Will Deacon
2020-10-20 20:16 ` Nick Desaulniers
@ 2020-12-14 21:44 ` Nick Desaulniers
2020-12-14 23:18 ` Alan Modra
1 sibling, 1 reply; 14+ messages in thread
From: Nick Desaulniers @ 2020-12-14 21:44 UTC (permalink / raw)
To: Alan Modra
Cc: Catalin Marinas, kernel-team, Will Deacon, LKML, Peter Smith,
clang-built-linux, # 3.4.x, Linux ARM, Ard Biesheuvel,
Fāng-ruì Sòng, Quentin Perret
On Tue, Oct 20, 2020 at 10:57 AM Will Deacon <will@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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
2020-12-14 21:44 ` Nick Desaulniers
@ 2020-12-14 23:18 ` Alan Modra
2020-12-14 23:33 ` Nick Desaulniers
0 siblings, 1 reply; 14+ messages in thread
From: Alan Modra @ 2020-12-14 23:18 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Catalin Marinas, kernel-team, Will Deacon, LKML, Peter Smith,
clang-built-linux, # 3.4.x, Linux ARM, Ard Biesheuvel,
Fāng-ruì Sòng, Quentin Perret
On Mon, Dec 14, 2020 at 01:44:06PM -0800, Nick Desaulniers wrote:
> aarch64-linux-gnu-ld: warning: -z norelro ignored
>
> So we set the emulation mode via -maarch64elf, and our preprocessed
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.
Now I don't know why the kernel uses -maarch64elf so you shouldn't
interpret my comment as a recommendation to use -maarch64linux
instead. That may have other unwanted effects.
--
Alan Modra
Australia Development Lab, IBM
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE
2020-12-14 23:18 ` Alan Modra
@ 2020-12-14 23:33 ` Nick Desaulniers
2020-12-17 0:40 ` [PATCH] arm64: link with -z norelro for LLD or aarch64-elf Nick Desaulniers
0 siblings, 1 reply; 14+ messages in thread
From: Nick Desaulniers @ 2020-12-14 23:33 UTC (permalink / raw)
To: Alan Modra
Cc: Catalin Marinas, kernel-team, Will Deacon, LKML, Peter Smith,
clang-built-linux, # 3.4.x, Linux ARM, Ard Biesheuvel,
Fāng-ruì Sòng, Quentin Perret
On Mon, Dec 14, 2020 at 3:18 PM Alan Modra <amodra@gmail.com> wrote:
>
> On Mon, Dec 14, 2020 at 01:44:06PM -0800, Nick Desaulniers wrote:
> > aarch64-linux-gnu-ld: warning: -z norelro ignored
> >
> > So we set the emulation mode via -maarch64elf, and our preprocessed
>
> 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.
>
> Now I don't know why the kernel uses -maarch64elf so you shouldn't
> interpret my comment as a recommendation to use -maarch64linux
> instead. That may have other unwanted effects.
Cool, thanks for the context. The kernel currently has:
arch/arm64/Makefile:
...
ifeq ($(CONFIG_CPU_BIG_ENDIAN), y)
...
# Prefer the baremetal ELF build target, but not all toolchains include
# it so fall back to the standard linux version if needed.
LDFLAGS += -EB $(call ld-option, -maarch64elfb, -maarch64linuxb)
...
else
...
# Same as above, prefer ELF but fall back to linux target if needed.
LDFLAGS += -EL $(call ld-option, -maarch64elf, -maarch64linux)
...
Then
$ git log -S maarch64elf arch/arm64/Makefile
provides more context:
1. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c931d34ea0853d41349e93f871bd3f17f1c03a6b
2. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=96f95a17c1cfe65a002e525114d96616e91a8f2d
3. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=38fc4248677552ce35efc09902fdcb06b61d7ef9
So it seems more that the kernel is relying on whichever emulation
targets are supported in local distros, not necessarily the semantic
differences between the two. Since the kernel might be linked as
either, I'll send the patch described in my last post to add `-z
norelro` just when linking with LLD, since it sounds like it's only
possible to specify when -maarch64linux/-maarch64linuxb is used, which
is unlikely.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] arm64: link with -z norelro for LLD or aarch64-elf
2020-12-14 23:33 ` Nick Desaulniers
@ 2020-12-17 0:40 ` Nick Desaulniers
2020-12-17 12:01 ` Will Deacon
2020-12-17 19:29 ` [PATCH] " Ard Biesheuvel
0 siblings, 2 replies; 14+ messages in thread
From: Nick Desaulniers @ 2020-12-17 0:40 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: kernel-team, Peter Smith, clang-built-linux, stable,
Ard Biesheuvel, Fāng-ruì Sòng, Quentin Perret,
Alan Modra, Nick Desaulniers, kernelci . org bot,
linux-arm-kernel, linux-kernel
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(-)
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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH] arm64: link with -z norelro for LLD or aarch64-elf
2020-12-17 0:40 ` [PATCH] arm64: link with -z norelro for LLD or aarch64-elf Nick Desaulniers
@ 2020-12-17 12:01 ` Will Deacon
2020-12-17 21:07 ` Nick Desaulniers
2020-12-17 19:29 ` [PATCH] " Ard Biesheuvel
1 sibling, 1 reply; 14+ messages in thread
From: Will Deacon @ 2020-12-17 12:01 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Catalin Marinas, kernel-team, Peter Smith, clang-built-linux,
stable, Ard Biesheuvel, Fāng-ruì Sòng,
Quentin Perret, Alan Modra, kernelci . org bot, linux-arm-kernel,
linux-kernel
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] arm64: link with -z norelro for LLD or aarch64-elf
2020-12-17 0:40 ` [PATCH] arm64: link with -z norelro for LLD or aarch64-elf Nick Desaulniers
2020-12-17 12:01 ` Will Deacon
@ 2020-12-17 19:29 ` Ard Biesheuvel
1 sibling, 0 replies; 14+ messages in thread
From: Ard Biesheuvel @ 2020-12-17 19:29 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Catalin Marinas, Will Deacon, kernel-team, Peter Smith,
clang-built-linux, stable, Fāng-ruì Sòng,
Quentin Perret, Alan Modra, kernelci . org bot, Linux ARM,
Linux Kernel Mailing List
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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH] arm64: link with -z norelro for LLD or aarch64-elf
2020-12-17 12:01 ` Will Deacon
@ 2020-12-17 21:07 ` Nick Desaulniers
2020-12-18 0:24 ` [PATCH v2] " Nick Desaulniers
0 siblings, 1 reply; 14+ messages in thread
From: Nick Desaulniers @ 2020-12-17 21:07 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, kernel-team, Peter Smith, clang-built-linux,
stable, Ard Biesheuvel, Fāng-ruì Sòng,
Quentin Perret, Alan Modra, kernelci . org bot, Linux ARM, LKML
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH v2] arm64: link with -z norelro for LLD or aarch64-elf
2020-12-17 21:07 ` Nick Desaulniers
@ 2020-12-18 0:24 ` Nick Desaulniers
2020-12-18 2:36 ` Nathan Chancellor
2021-01-05 12:26 ` Catalin Marinas
0 siblings, 2 replies; 14+ messages in thread
From: Nick Desaulniers @ 2020-12-18 0:24 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: kernel-team, Peter Smith, clang-built-linux, stable,
Ard Biesheuvel, Fāng-ruì Sòng, Quentin Perret,
Alan Modra, Nick Desaulniers, kernelci . org bot,
linux-arm-kernel, linux-kernel
With GNU binutils 2.35+, 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 program headers, 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 program header 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: 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>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
---
Changes V1 -> V2:
* s/relocation types/program headers/
* s/newer GNU binutils/GNU binutils 2.35+/
* Pick up Ard's Ack.
Note: maintainers may want to pick up the following tag:
Fixes: 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker script and options")
or drop the existing fixes tag (this patch is more so in response to
change to BFD to warn than fix a kernel regression, IMO, but I don't
care). Either way, it would be good to fix this for the newly minted
v5.10.y.
I'll probably be offline for the next two weeks for the holidays, so no
promises on quick replies. Happy holidays+new year!
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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [PATCH v2] arm64: link with -z norelro for LLD or aarch64-elf
2020-12-18 0:24 ` [PATCH v2] " Nick Desaulniers
@ 2020-12-18 2:36 ` Nathan Chancellor
2021-01-05 12:26 ` Catalin Marinas
1 sibling, 0 replies; 14+ messages in thread
From: Nathan Chancellor @ 2020-12-18 2:36 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Catalin Marinas, Will Deacon, kernel-team, Peter Smith,
clang-built-linux, stable, Ard Biesheuvel,
Fāng-ruì Sòng, Quentin Perret, Alan Modra,
kernelci . org bot, linux-arm-kernel, linux-kernel
On Thu, Dec 17, 2020 at 04:24:32PM -0800, 'Nick Desaulniers' via Clang Built Linux wrote:
> With GNU binutils 2.35+, 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 program headers, 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 program header 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: 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>
> Acked-by: Ard Biesheuvel <ardb@kernel.org>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> Changes V1 -> V2:
> * s/relocation types/program headers/
> * s/newer GNU binutils/GNU binutils 2.35+/
> * Pick up Ard's Ack.
>
> Note: maintainers may want to pick up the following tag:
>
> Fixes: 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker script and options")
>
> or drop the existing fixes tag (this patch is more so in response to
> change to BFD to warn than fix a kernel regression, IMO, but I don't
> care). Either way, it would be good to fix this for the newly minted
> v5.10.y.
Should probably have
Cc: stable@vger.kernel.org
then.
> I'll probably be offline for the next two weeks for the holidays, so no
> promises on quick replies. Happy holidays+new year!
>
>
> 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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [PATCH v2] arm64: link with -z norelro for LLD or aarch64-elf
2020-12-18 0:24 ` [PATCH v2] " Nick Desaulniers
2020-12-18 2:36 ` Nathan Chancellor
@ 2021-01-05 12:26 ` Catalin Marinas
1 sibling, 0 replies; 14+ messages in thread
From: Catalin Marinas @ 2021-01-05 12:26 UTC (permalink / raw)
To: Will Deacon, Nick Desaulniers
Cc: kernel-team, kernelci . org bot, linux-arm-kernel,
Fāng-ruì Sòng, Alan Modra, Ard Biesheuvel,
Peter Smith, Quentin Perret, linux-kernel, stable,
clang-built-linux
On Thu, 17 Dec 2020 16:24:32 -0800, Nick Desaulniers wrote:
> With GNU binutils 2.35+, 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 program headers, 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.
>
> [...]
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64: link with -z norelro for LLD or aarch64-elf
https://git.kernel.org/arm64/c/311bea3cb9ee
Also added the second Fixes tag with a cc stable.
--
Catalin
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2021-01-05 12:27 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-16 17:53 [PATCH] arm64: link with -z norelro regardless of CONFIG_RELOCATABLE Nick Desaulniers
2020-10-20 17:57 ` Will Deacon
2020-10-20 20:16 ` Nick Desaulniers
2020-10-21 6:58 ` Ard Biesheuvel
2020-12-14 21:44 ` Nick Desaulniers
2020-12-14 23:18 ` Alan Modra
2020-12-14 23:33 ` Nick Desaulniers
2020-12-17 0:40 ` [PATCH] arm64: link with -z norelro for LLD or aarch64-elf Nick Desaulniers
2020-12-17 12:01 ` Will Deacon
2020-12-17 21:07 ` Nick Desaulniers
2020-12-18 0:24 ` [PATCH v2] " Nick Desaulniers
2020-12-18 2:36 ` Nathan Chancellor
2021-01-05 12:26 ` Catalin Marinas
2020-12-17 19:29 ` [PATCH] " Ard Biesheuvel
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 NNTP newsgroup(s).