Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
script and options") added '-z norelro' to the arm64 Makefile when
CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
defaults to '-z relro' but the kernel does not use program headers or
adhere to the section layout that is required for RELRO to work.
Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
unset.
As it turns out, ARM experiences the same error after CONFIG_KASAN was
implemented, meaning that '-z norelro' needs to be added to that
Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
$ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
ld.lld: error: section: .exit.data is not contiguous with other relro sections
To avoid playing whack-a-mole with different architectures over time,
hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
because '-z norelro' is the default for it.
Link: https://github.com/ClangBuiltLinux/linux/issues/1189
Suggested-by: Nick Desaulniers <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
---
Hi all,
This should probably go into Russell's tree with acks from the arm64 and
kbuild maintainers.
Cheers,
Nathan
Makefile | 2 ++
arch/arm64/Makefile | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/Makefile b/Makefile
index 008aba5f1a20..648bfb486244 100644
--- a/Makefile
+++ b/Makefile
@@ -984,6 +984,8 @@ ifeq ($(CONFIG_RELR),y)
LDFLAGS_vmlinux += --pack-dyn-relocs=relr
endif
+LDFLAGS_vmlinux += -z norelro
+
# Align the bit size of userspace programs with the kernel
KBUILD_USERCFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 5789c2d18d43..85495ff8f0fd 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
base-commit: f8394f232b1eab649ce2df5c5f15b0e528c92091
--
2.29.2
On Thu, Nov 12, 2020 at 10:41 AM Nathan Chancellor
<[email protected]> wrote:
>
> Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
> script and options") added '-z norelro' to the arm64 Makefile when
> CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
> defaults to '-z relro' but the kernel does not use program headers or
> adhere to the section layout that is required for RELRO to work.
>
> Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
> CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
> an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
> unset.
>
> As it turns out, ARM experiences the same error after CONFIG_KASAN was
> implemented, meaning that '-z norelro' needs to be added to that
> Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
>
> $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> ld.lld: error: section: .exit.data is not contiguous with other relro sections
>
> To avoid playing whack-a-mole with different architectures over time,
> hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> because '-z norelro' is the default for it.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> Suggested-by: Nick Desaulniers <[email protected]>
> Signed-off-by: Nathan Chancellor <[email protected]>
Why not add it additionally to KBUILD_LDFLAGS_MODULE a la
`--build-id=sha1` a few lines above? (or `LDFLAGS_MODULE`, but that
looks unused?) We probably don't want this for modules either. In
that case, you could add -z norelo to the two existing lines with
`--build-id=sha1` above?
> ---
>
> Hi all,
>
> This should probably go into Russell's tree with acks from the arm64 and
> kbuild maintainers.
>
> Cheers,
> Nathan
>
> Makefile | 2 ++
> arch/arm64/Makefile | 2 +-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Makefile b/Makefile
> index 008aba5f1a20..648bfb486244 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -984,6 +984,8 @@ ifeq ($(CONFIG_RELR),y)
> LDFLAGS_vmlinux += --pack-dyn-relocs=relr
> endif
>
> +LDFLAGS_vmlinux += -z norelro
> +
> # Align the bit size of userspace programs with the kernel
> KBUILD_USERCFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
> KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 5789c2d18d43..85495ff8f0fd 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
>
> base-commit: f8394f232b1eab649ce2df5c5f15b0e528c92091
> --
> 2.29.2
>
--
Thanks,
~Nick Desaulniers
On Thu, Nov 12, 2020 at 04:44:46PM -0800, Nick Desaulniers wrote:
> On Thu, Nov 12, 2020 at 10:41 AM Nathan Chancellor
> <[email protected]> wrote:
> >
> > Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
> > script and options") added '-z norelro' to the arm64 Makefile when
> > CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
> > defaults to '-z relro' but the kernel does not use program headers or
> > adhere to the section layout that is required for RELRO to work.
> >
> > Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
> > CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
> > an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
> > unset.
> >
> > As it turns out, ARM experiences the same error after CONFIG_KASAN was
> > implemented, meaning that '-z norelro' needs to be added to that
> > Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
> >
> > $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> >
> > To avoid playing whack-a-mole with different architectures over time,
> > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > because '-z norelro' is the default for it.
> >
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> > Suggested-by: Nick Desaulniers <[email protected]>
> > Signed-off-by: Nathan Chancellor <[email protected]>
>
> Why not add it additionally to KBUILD_LDFLAGS_MODULE a la
> `--build-id=sha1` a few lines above? (or `LDFLAGS_MODULE`, but that
> looks unused?) We probably don't want this for modules either. In
> that case, you could add -z norelo to the two existing lines with
> `--build-id=sha1` above?
Yes, I can do that. I will send a v2 along tomorrow morning to let
others comment.
Cheers,
Nathan
On Fri, 13 Nov 2020 at 01:53, Nathan Chancellor
<[email protected]> wrote:
>
> On Thu, Nov 12, 2020 at 04:44:46PM -0800, Nick Desaulniers wrote:
> > On Thu, Nov 12, 2020 at 10:41 AM Nathan Chancellor
> > <[email protected]> wrote:
> > >
> > > Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
> > > script and options") added '-z norelro' to the arm64 Makefile when
> > > CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
> > > defaults to '-z relro' but the kernel does not use program headers or
> > > adhere to the section layout that is required for RELRO to work.
> > >
> > > Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
> > > CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
> > > an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
> > > unset.
> > >
> > > As it turns out, ARM experiences the same error after CONFIG_KASAN was
> > > implemented, meaning that '-z norelro' needs to be added to that
> > > Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
> > >
> > > $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > >
> > > To avoid playing whack-a-mole with different architectures over time,
> > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > because '-z norelro' is the default for it.
> > >
> > > Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> > > Suggested-by: Nick Desaulniers <[email protected]>
> > > Signed-off-by: Nathan Chancellor <[email protected]>
> >
> > Why not add it additionally to KBUILD_LDFLAGS_MODULE a la
> > `--build-id=sha1` a few lines above? (or `LDFLAGS_MODULE`, but that
> > looks unused?) We probably don't want this for modules either. In
> > that case, you could add -z norelo to the two existing lines with
> > `--build-id=sha1` above?
>
> Yes, I can do that. I will send a v2 along tomorrow morning to let
> others comment.
>
Modules are partially linked objects, so there is no point in passing
-z options for them.
On Thu, Nov 12, 2020 at 10:06 PM Ard Biesheuvel <[email protected]> wrote:
>
> On Fri, 13 Nov 2020 at 01:53, Nathan Chancellor
> <[email protected]> wrote:
> >
> > On Thu, Nov 12, 2020 at 04:44:46PM -0800, Nick Desaulniers wrote:
> > > On Thu, Nov 12, 2020 at 10:41 AM Nathan Chancellor
> > > <[email protected]> wrote:
> > > >
> > > > Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
> > > > script and options") added '-z norelro' to the arm64 Makefile when
> > > > CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
> > > > defaults to '-z relro' but the kernel does not use program headers or
> > > > adhere to the section layout that is required for RELRO to work.
> > > >
> > > > Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
> > > > CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
> > > > an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
> > > > unset.
> > > >
> > > > As it turns out, ARM experiences the same error after CONFIG_KASAN was
> > > > implemented, meaning that '-z norelro' needs to be added to that
> > > > Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
> > > >
> > > > $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> > > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > >
> > > > To avoid playing whack-a-mole with different architectures over time,
> > > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > > because '-z norelro' is the default for it.
> > > >
> > > > Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> > > > Suggested-by: Nick Desaulniers <[email protected]>
> > > > Signed-off-by: Nathan Chancellor <[email protected]>
> > >
> > > Why not add it additionally to KBUILD_LDFLAGS_MODULE a la
> > > `--build-id=sha1` a few lines above? (or `LDFLAGS_MODULE`, but that
> > > looks unused?) We probably don't want this for modules either. In
> > > that case, you could add -z norelo to the two existing lines with
> > > `--build-id=sha1` above?
> >
> > Yes, I can do that. I will send a v2 along tomorrow morning to let
> > others comment.
> >
>
> Modules are partially linked objects, so there is no point in passing
> -z options for them.
Ok then.
Reviewed-by: Nick Desaulniers <[email protected]>
Tested-by: Nick Desaulniers <[email protected]>
More work to be done to boot this config, but at least we can link
without error.
--
Thanks,
~Nick Desaulniers
On Thu, Nov 12, 2020 at 11:38:40AM -0700, Nathan Chancellor wrote:
> Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
> script and options") added '-z norelro' to the arm64 Makefile when
> CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
> defaults to '-z relro' but the kernel does not use program headers or
> adhere to the section layout that is required for RELRO to work.
>
> Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
> CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
> an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
> unset.
>
> As it turns out, ARM experiences the same error after CONFIG_KASAN was
> implemented, meaning that '-z norelro' needs to be added to that
> Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
>
> $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> ld.lld: error: section: .exit.data is not contiguous with other relro sections
>
> To avoid playing whack-a-mole with different architectures over time,
> hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> because '-z norelro' is the default for it.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> Suggested-by: Nick Desaulniers <[email protected]>
> Signed-off-by: Nathan Chancellor <[email protected]>
> ---
>
> Hi all,
>
> This should probably go into Russell's tree with acks from the arm64 and
> kbuild maintainers.
So that's a fix for arch/arm going in the top Makefile.
For the arm64 part:
Acked-by: Catalin Marinas <[email protected]>
On Thu, Nov 12, 2020 at 7:41 PM Nathan Chancellor
<[email protected]> wrote:
> Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
> script and options") added '-z norelro' to the arm64 Makefile when
> CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
> defaults to '-z relro' but the kernel does not use program headers or
> adhere to the section layout that is required for RELRO to work.
>
> Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
> CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
> an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
> unset.
>
> As it turns out, ARM experiences the same error after CONFIG_KASAN was
> implemented, meaning that '-z norelro' needs to be added to that
> Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
>
> $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> ld.lld: error: section: .exit.data is not contiguous with other relro sections
>
> To avoid playing whack-a-mole with different architectures over time,
> hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> because '-z norelro' is the default for it.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1189
> Suggested-by: Nick Desaulniers <[email protected]>
> Signed-off-by: Nathan Chancellor <[email protected]>
OK makes sense, FWIW:
Reviewed-by: Linus Walleij <[email protected]>
Yours,
Linus Walleij
On Fri, Nov 13, 2020 at 11:34 AM Nick Desaulniers
<[email protected]> wrote:
>
> On Thu, Nov 12, 2020 at 10:06 PM Ard Biesheuvel <[email protected]> wrote:
> >
> > On Fri, 13 Nov 2020 at 01:53, Nathan Chancellor
> > <[email protected]> wrote:
> > >
> > > On Thu, Nov 12, 2020 at 04:44:46PM -0800, Nick Desaulniers wrote:
> > > > On Thu, Nov 12, 2020 at 10:41 AM Nathan Chancellor
> > > > <[email protected]> wrote:
> > > > >
> > > > > Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
> > > > > script and options") added '-z norelro' to the arm64 Makefile when
> > > > > CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
> > > > > defaults to '-z relro' but the kernel does not use program headers or
> > > > > adhere to the section layout that is required for RELRO to work.
> > > > >
> > > > > Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
> > > > > CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
> > > > > an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
> > > > > unset.
> > > > >
> > > > > As it turns out, ARM experiences the same error after CONFIG_KASAN was
> > > > > implemented, meaning that '-z norelro' needs to be added to that
> > > > > Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
> > > > >
> > > > > $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> > > > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > > >
> > > > > To avoid playing whack-a-mole with different architectures over time,
> > > > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > > > because '-z norelro' is the default for it.
Fangrui pointed out off list that this might need an ld-option wrapper
for older versions of GNU binutils. Dan was showing me some build
logs today, and I thought I spotted such warnings about `-z norelro
will be ignored`.
--
Thanks,
~Nick Desaulniers
On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <[email protected]> wrote:
>
> On Fri, Nov 13, 2020 at 11:34 AM Nick Desaulniers
> <[email protected]> wrote:
> >
> > On Thu, Nov 12, 2020 at 10:06 PM Ard Biesheuvel <[email protected]> wrote:
> > >
> > > On Fri, 13 Nov 2020 at 01:53, Nathan Chancellor
> > > <[email protected]> wrote:
> > > >
> > > > On Thu, Nov 12, 2020 at 04:44:46PM -0800, Nick Desaulniers wrote:
> > > > > On Thu, Nov 12, 2020 at 10:41 AM Nathan Chancellor
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > Commit 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker
> > > > > > script and options") added '-z norelro' to the arm64 Makefile when
> > > > > > CONFIG_RELOCATABLE was set to help support ld.lld because ld.lld
> > > > > > defaults to '-z relro' but the kernel does not use program headers or
> > > > > > adhere to the section layout that is required for RELRO to work.
> > > > > >
> > > > > > Commit 3b92fa7485eb ("arm64: link with -z norelro regardless of
> > > > > > CONFIG_RELOCATABLE") unconditionally added it to LDFLAGS_vmlinux because
> > > > > > an error occurs with CONFIG_KASAN set even when CONFIG_RELOCATABLE is
> > > > > > unset.
> > > > > >
> > > > > > As it turns out, ARM experiences the same error after CONFIG_KASAN was
> > > > > > implemented, meaning that '-z norelro' needs to be added to that
> > > > > > Makefile as well (multi_v7_defconfig + CONFIG_KASAN=y + LD=ld.lld):
> > > > > >
> > > > > > $ make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- LLVM=1 zImage
> > > > > > ld.lld: error: section: .exit.data is not contiguous with other relro sections
> > > > > >
> > > > > > To avoid playing whack-a-mole with different architectures over time,
> > > > > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > > > > because '-z norelro' is the default for it.
>
> Fangrui pointed out off list that this might need an ld-option wrapper
> for older versions of GNU binutils. Dan was showing me some build
> logs today, and I thought I spotted such warnings about `-z norelro
> will be ignored`.
Does ld-option catch options that cause warnings but no errors?
On Wed, Nov 18, 2020 at 3:07 PM Ard Biesheuvel <[email protected]> wrote:
>
> On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <[email protected]> wrote:
> >
> > > > > > > To avoid playing whack-a-mole with different architectures over time,
> > > > > > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > > > > > because '-z norelro' is the default for it.
> >
> > Fangrui pointed out off list that this might need an ld-option wrapper
> > for older versions of GNU binutils. Dan was showing me some build
> > logs today, and I thought I spotted such warnings about `-z norelro
> > will be ignored`.
>
> Does ld-option catch options that cause warnings but no errors?
$ ld.bfd -z foo /dev/null
ld.bfd: warning: -z foo ignored
ld.bfd: warning: cannot find entry symbol _start; not setting start address
➜ echo $?
0
Probably not. Can be a version check then (yuck); next is to find when
ld.bfd supported `-z norelro`.
commit 8c37241be3b1 in binutils looks like it.
Date: Tue May 11 17:08:38 2004 +0000
which looks like either
2004-05-17 19:46:23 +0000 (tag: binutils-2_15)
or
2005-05-02 22:04:18 +0000 (tag: binutils-2_16)
So I think that would be fine then, since the kernel only supports 2.23+.
Though maybe it's
commit 5fd104addfddb68844fb8df67be832ee98ad9888
Emit a warning when -z relro is unsupported
ld silently accepts -z relro and -z norelro for targets that lack the
necessary GNU_RELRO support. This patch makes those targets emit a
warning instead, and adds testsuite infrastructure to detect when
relro is unsupported.
So maybe then alpha and xtensa are getting new warnings (IIUC). If
that's the case, then we might not be able to set `-z norelro`
globally, and instead have to play whack a mole per architecture.
--
Thanks,
~Nick Desaulniers
On Wed, Nov 18, 2020 at 03:24:04PM -0800, Nick Desaulniers wrote:
> On Wed, Nov 18, 2020 at 3:07 PM Ard Biesheuvel <[email protected]> wrote:
> >
> > On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <[email protected]> wrote:
> > >
> > > > > > > > To avoid playing whack-a-mole with different architectures over time,
> > > > > > > > hoist '-z norelro' into the main Makefile. This does not affect ld.bfd
> > > > > > > > because '-z norelro' is the default for it.
> > >
> > > Fangrui pointed out off list that this might need an ld-option wrapper
> > > for older versions of GNU binutils. Dan was showing me some build
> > > logs today, and I thought I spotted such warnings about `-z norelro
> > > will be ignored`.
> >
> > Does ld-option catch options that cause warnings but no errors?
>
> $ ld.bfd -z foo /dev/null
> ld.bfd: warning: -z foo ignored
> ld.bfd: warning: cannot find entry symbol _start; not setting start address
> ➜ echo $?
> 0
>
> Probably not. Can be a version check then (yuck); next is to find when
> ld.bfd supported `-z norelro`.
>
> commit 8c37241be3b1 in binutils looks like it.
> Date: Tue May 11 17:08:38 2004 +0000
>
> which looks like either
> 2004-05-17 19:46:23 +0000 (tag: binutils-2_15)
> or
> 2005-05-02 22:04:18 +0000 (tag: binutils-2_16)
>
> So I think that would be fine then, since the kernel only supports 2.23+.
>
> Though maybe it's
> commit 5fd104addfddb68844fb8df67be832ee98ad9888
> Emit a warning when -z relro is unsupported
>
> ld silently accepts -z relro and -z norelro for targets that lack the
> necessary GNU_RELRO support. This patch makes those targets emit a
> warning instead, and adds testsuite infrastructure to detect when
> relro is unsupported.
>
> So maybe then alpha and xtensa are getting new warnings (IIUC). If
> that's the case, then we might not be able to set `-z norelro`
> globally, and instead have to play whack a mole per architecture.
Sure, I can just submit the arch/arm patch that I had before this for
now and we can always revisit something like this later, if you feel it
is best.
Cheers,
Nathan