diff mbox series

kbuild: Always link with '-z norelro'

Message ID 20201112183839.1009297-1-natechancellor@gmail.com (mailing list archive)
State New
Headers show
Series kbuild: Always link with '-z norelro' | expand

Commit Message

Nathan Chancellor Nov. 12, 2020, 6:38 p.m. UTC
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 <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
---

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(-)


base-commit: f8394f232b1eab649ce2df5c5f15b0e528c92091

Comments

Nick Desaulniers Nov. 13, 2020, 12:44 a.m. UTC | #1
On Thu, Nov 12, 2020 at 10:41 AM Nathan Chancellor
<natechancellor@gmail.com> 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 <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

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
>
Nathan Chancellor Nov. 13, 2020, 12:53 a.m. UTC | #2
On Thu, Nov 12, 2020 at 04:44:46PM -0800, Nick Desaulniers wrote:
> On Thu, Nov 12, 2020 at 10:41 AM Nathan Chancellor
> <natechancellor@gmail.com> 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 <ndesaulniers@google.com>
> > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> 
> 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
Ard Biesheuvel Nov. 13, 2020, 6:06 a.m. UTC | #3
On Fri, 13 Nov 2020 at 01:53, Nathan Chancellor
<natechancellor@gmail.com> 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
> > <natechancellor@gmail.com> 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 <ndesaulniers@google.com>
> > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> >
> > 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.
Nick Desaulniers Nov. 13, 2020, 7:34 p.m. UTC | #4
On Thu, Nov 12, 2020 at 10:06 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 13 Nov 2020 at 01:53, Nathan Chancellor
> <natechancellor@gmail.com> 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
> > > <natechancellor@gmail.com> 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 <ndesaulniers@google.com>
> > > > Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> > >
> > > 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 <ndesaulniers@google.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>

More work to be done to boot this config, but at least we can link
without error.
Catalin Marinas Nov. 16, 2020, 12:31 p.m. UTC | #5
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 <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
> ---
> 
> 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 <catalin.marinas@arm.com>
Linus Walleij Nov. 17, 2020, 9:17 p.m. UTC | #6
On Thu, Nov 12, 2020 at 7:41 PM Nathan Chancellor
<natechancellor@gmail.com> 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 <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>

OK makes sense, FWIW:
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>

Yours,
Linus Walleij
Nick Desaulniers Nov. 18, 2020, 11:05 p.m. UTC | #7
On Fri, Nov 13, 2020 at 11:34 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Thu, Nov 12, 2020 at 10:06 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Fri, 13 Nov 2020 at 01:53, Nathan Chancellor
> > <natechancellor@gmail.com> 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
> > > > <natechancellor@gmail.com> 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`.
Ard Biesheuvel Nov. 18, 2020, 11:06 p.m. UTC | #8
On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <ndesaulniers@google.com> wrote:
>
> On Fri, Nov 13, 2020 at 11:34 AM Nick Desaulniers
> <ndesaulniers@google.com> wrote:
> >
> > On Thu, Nov 12, 2020 at 10:06 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> > >
> > > On Fri, 13 Nov 2020 at 01:53, Nathan Chancellor
> > > <natechancellor@gmail.com> 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
> > > > > <natechancellor@gmail.com> 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?
Nick Desaulniers Nov. 18, 2020, 11:24 p.m. UTC | #9
On Wed, Nov 18, 2020 at 3:07 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <ndesaulniers@google.com> 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.
Nathan Chancellor Nov. 19, 2020, 7:33 p.m. UTC | #10
On Wed, Nov 18, 2020 at 03:24:04PM -0800, Nick Desaulniers wrote:
> On Wed, Nov 18, 2020 at 3:07 PM Ard Biesheuvel <ardb@kernel.org> wrote:
> >
> > On Thu, 19 Nov 2020 at 00:05, Nick Desaulniers <ndesaulniers@google.com> 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
diff mbox series

Patch

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