Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instance
of a new warning when linking kernels in the form:
ld: warning: arch/x86/realmode/rm/bioscall.o: missing .note.GNU-stack
section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future
version of the linker
The object files producing these all happen to be out of line assembler
sources (*.S files).
Generally, we would like to avoid the stack being executable. Because
there could be a need for the stack to be executable, assembler sources
have to opt-in to this security feature via explicit creation of the
.note.GNU-stack feature (which compilers create by default) or command
line flag --noexecstack.
Boot tested defconfig and i386_defconfig in QEMU. If any assembler
sources do require executable stack, they can be built with
-Wa,--execstack, though the linker warning would have to be disabled. We
might need to extend this more generally to the top level Makefile for
all architectures, but I'm not equipped to test the result of such a
change.
LLVM's LLD linker defaults to -z noexecstack, so this flag isn't
strictly necessary when linking with LLD, only BFD, but it doesn't hurt
to be explicit here for all linkers IMO.
Link: https://lore.kernel.org/linux-block/[email protected]/
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
Link: https://github.com/llvm/llvm-project/issues/57009
Reported-by: Jens Axboe <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
---
arch/x86/Makefile | 2 ++
arch/x86/boot/Makefile | 2 +-
arch/x86/boot/compressed/Makefile | 2 +-
arch/x86/realmode/rm/Makefile | 2 +-
4 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 7854685c5f25..571546775725 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -159,6 +159,8 @@ else
KBUILD_CFLAGS += -mcmodel=kernel
endif
+KBUILD_AFLAGS += -Wa,--noexecstack
+
#
# If the function graph tracer is used with mcount instead of fentry,
# '-maccumulate-outgoing-args' is needed to prevent a GCC bug
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index b5aecb524a8a..d7f2130f2277 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -67,7 +67,7 @@ targets += cpustr.h
# ---------------------------------------------------------------------------
KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP
-KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
+KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -Wa,--noexecstack
KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
GCOV_PROFILE := n
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 19e1905dcbf6..1587a21a132d 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -57,7 +57,7 @@ KBUILD_CFLAGS += -include $(srctree)/include/linux/hidden.h
# that the compiler finds it even with out-of-tree builds (make O=/some/path).
CFLAGS_sev.o += -I$(objtree)/arch/x86/lib/
-KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
+KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -Wa,--noexecstack
GCOV_PROFILE := n
UBSAN_SANITIZE :=n
diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
index 83f1b6a56449..5f2fdafaa034 100644
--- a/arch/x86/realmode/rm/Makefile
+++ b/arch/x86/realmode/rm/Makefile
@@ -73,7 +73,7 @@ $(obj)/realmode.relocs: $(obj)/realmode.elf FORCE
KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \
-I$(srctree)/arch/x86/boot
-KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
+KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -Wa,--noexecstack
KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
GCOV_PROFILE := n
UBSAN_SANITIZE := n
--
2.37.1.559.g78731f0fdb-goog
On Mon, Aug 08, 2022 at 12:23:05PM -0700, Nick Desaulniers wrote:
> Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instance
> of a new warning when linking kernels in the form:
>
> ld: warning: arch/x86/realmode/rm/bioscall.o: missing .note.GNU-stack
> section implies executable stack
> ld: NOTE: This behaviour is deprecated and will be removed in a future
> version of the linker
>
> The object files producing these all happen to be out of line assembler
> sources (*.S files).
>
> Generally, we would like to avoid the stack being executable. Because
> there could be a need for the stack to be executable, assembler sources
> have to opt-in to this security feature via explicit creation of the
> .note.GNU-stack feature (which compilers create by default) or command
> line flag --noexecstack.
>
> Boot tested defconfig and i386_defconfig in QEMU. If any assembler
> sources do require executable stack, they can be built with
> -Wa,--execstack, though the linker warning would have to be disabled. We
> might need to extend this more generally to the top level Makefile for
> all architectures, but I'm not equipped to test the result of such a
> change.
>
> LLVM's LLD linker defaults to -z noexecstack, so this flag isn't
> strictly necessary when linking with LLD, only BFD, but it doesn't hurt
> to be explicit here for all linkers IMO.
>
> Link: https://lore.kernel.org/linux-block/[email protected]/
> Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
> Link: https://github.com/llvm/llvm-project/issues/57009
> Reported-by: Jens Axboe <[email protected]>
> Signed-off-by: Nick Desaulniers <[email protected]>
FWIW, this warning appears for other architectures, as I have seen it
with powerpc and s390 and there is also a patch for ARM:
https://lore.kernel.org/[email protected]/
Perhaps this should be done for all architectures in the main Makefile?
> ---
> arch/x86/Makefile | 2 ++
> arch/x86/boot/Makefile | 2 +-
> arch/x86/boot/compressed/Makefile | 2 +-
> arch/x86/realmode/rm/Makefile | 2 +-
> 4 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> index 7854685c5f25..571546775725 100644
> --- a/arch/x86/Makefile
> +++ b/arch/x86/Makefile
> @@ -159,6 +159,8 @@ else
> KBUILD_CFLAGS += -mcmodel=kernel
> endif
>
> +KBUILD_AFLAGS += -Wa,--noexecstack
> +
> #
> # If the function graph tracer is used with mcount instead of fentry,
> # '-maccumulate-outgoing-args' is needed to prevent a GCC bug
> diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
> index b5aecb524a8a..d7f2130f2277 100644
> --- a/arch/x86/boot/Makefile
> +++ b/arch/x86/boot/Makefile
> @@ -67,7 +67,7 @@ targets += cpustr.h
> # ---------------------------------------------------------------------------
>
> KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP
> -KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
> +KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -Wa,--noexecstack
> KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
> KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
> GCOV_PROFILE := n
> diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
> index 19e1905dcbf6..1587a21a132d 100644
> --- a/arch/x86/boot/compressed/Makefile
> +++ b/arch/x86/boot/compressed/Makefile
> @@ -57,7 +57,7 @@ KBUILD_CFLAGS += -include $(srctree)/include/linux/hidden.h
> # that the compiler finds it even with out-of-tree builds (make O=/some/path).
> CFLAGS_sev.o += -I$(objtree)/arch/x86/lib/
>
> -KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
> +KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -Wa,--noexecstack
> GCOV_PROFILE := n
> UBSAN_SANITIZE :=n
>
> diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
> index 83f1b6a56449..5f2fdafaa034 100644
> --- a/arch/x86/realmode/rm/Makefile
> +++ b/arch/x86/realmode/rm/Makefile
> @@ -73,7 +73,7 @@ $(obj)/realmode.relocs: $(obj)/realmode.elf FORCE
>
> KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \
> -I$(srctree)/arch/x86/boot
> -KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
> +KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -Wa,--noexecstack
> KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
> GCOV_PROFILE := n
> UBSAN_SANITIZE := n
> --
> 2.37.1.559.g78731f0fdb-goog
>
On Mon, Aug 8, 2022 at 12:31 PM Nathan Chancellor <[email protected]> wrote:
>
> On Mon, Aug 08, 2022 at 12:23:05PM -0700, Nick Desaulniers wrote:
> > Users of GNU ld (BFD) from binutils 2.39+ will observe multiple instance
> > of a new warning when linking kernels in the form:
> >
> > ld: warning: arch/x86/realmode/rm/bioscall.o: missing .note.GNU-stack
> > section implies executable stack
> > ld: NOTE: This behaviour is deprecated and will be removed in a future
> > version of the linker
> >
> > The object files producing these all happen to be out of line assembler
> > sources (*.S files).
> >
> > Generally, we would like to avoid the stack being executable. Because
> > there could be a need for the stack to be executable, assembler sources
> > have to opt-in to this security feature via explicit creation of the
> > .note.GNU-stack feature (which compilers create by default) or command
> > line flag --noexecstack.
> >
> > Boot tested defconfig and i386_defconfig in QEMU. If any assembler
> > sources do require executable stack, they can be built with
> > -Wa,--execstack, though the linker warning would have to be disabled. We
> > might need to extend this more generally to the top level Makefile for
> > all architectures, but I'm not equipped to test the result of such a
> > change.
> >
> > LLVM's LLD linker defaults to -z noexecstack, so this flag isn't
> > strictly necessary when linking with LLD, only BFD, but it doesn't hurt
> > to be explicit here for all linkers IMO.
> >
> > Link: https://lore.kernel.org/linux-block/[email protected]/
> > Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
> > Link: https://github.com/llvm/llvm-project/issues/57009
> > Reported-by: Jens Axboe <[email protected]>
> > Signed-off-by: Nick Desaulniers <[email protected]>
>
> FWIW, this warning appears for other architectures, as I have seen it
> with powerpc and s390 and there is also a patch for ARM:
>
> https://lore.kernel.org/[email protected]/
>
> Perhaps this should be done for all architectures in the main Makefile?
Thanks for the link; I recall Ard mentioning the ELF segments are
ignored by the kernels loader in another thread.
Perhaps we should be adding
--no-warn-execstack
wrapped in an ld-option check to KBUILD_LDFLAGS at the top level?
>
> > ---
> > arch/x86/Makefile | 2 ++
> > arch/x86/boot/Makefile | 2 +-
> > arch/x86/boot/compressed/Makefile | 2 +-
> > arch/x86/realmode/rm/Makefile | 2 +-
> > 4 files changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/x86/Makefile b/arch/x86/Makefile
> > index 7854685c5f25..571546775725 100644
> > --- a/arch/x86/Makefile
> > +++ b/arch/x86/Makefile
> > @@ -159,6 +159,8 @@ else
> > KBUILD_CFLAGS += -mcmodel=kernel
> > endif
> >
> > +KBUILD_AFLAGS += -Wa,--noexecstack
> > +
> > #
> > # If the function graph tracer is used with mcount instead of fentry,
> > # '-maccumulate-outgoing-args' is needed to prevent a GCC bug
> > diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
> > index b5aecb524a8a..d7f2130f2277 100644
> > --- a/arch/x86/boot/Makefile
> > +++ b/arch/x86/boot/Makefile
> > @@ -67,7 +67,7 @@ targets += cpustr.h
> > # ---------------------------------------------------------------------------
> >
> > KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP
> > -KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
> > +KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -Wa,--noexecstack
> > KBUILD_CFLAGS += $(call cc-option,-fmacro-prefix-map=$(srctree)/=)
> > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
> > GCOV_PROFILE := n
> > diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
> > index 19e1905dcbf6..1587a21a132d 100644
> > --- a/arch/x86/boot/compressed/Makefile
> > +++ b/arch/x86/boot/compressed/Makefile
> > @@ -57,7 +57,7 @@ KBUILD_CFLAGS += -include $(srctree)/include/linux/hidden.h
> > # that the compiler finds it even with out-of-tree builds (make O=/some/path).
> > CFLAGS_sev.o += -I$(objtree)/arch/x86/lib/
> >
> > -KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
> > +KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -Wa,--noexecstack
> > GCOV_PROFILE := n
> > UBSAN_SANITIZE :=n
> >
> > diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
> > index 83f1b6a56449..5f2fdafaa034 100644
> > --- a/arch/x86/realmode/rm/Makefile
> > +++ b/arch/x86/realmode/rm/Makefile
> > @@ -73,7 +73,7 @@ $(obj)/realmode.relocs: $(obj)/realmode.elf FORCE
> >
> > KBUILD_CFLAGS := $(REALMODE_CFLAGS) -D_SETUP -D_WAKEUP \
> > -I$(srctree)/arch/x86/boot
> > -KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__
> > +KBUILD_AFLAGS := $(KBUILD_CFLAGS) -D__ASSEMBLY__ -Wa,--noexecstack
> > KBUILD_CFLAGS += -fno-asynchronous-unwind-tables
> > GCOV_PROFILE := n
> > UBSAN_SANITIZE := n
> > --
> > 2.37.1.559.g78731f0fdb-goog
> >
--
Thanks,
~Nick Desaulniers
On Mon, Aug 8, 2022 at 1:32 PM Nick Desaulniers <[email protected]> wrote:
>
> Thanks for the link; I recall Ard mentioning the ELF segments are
> ignored by the kernels loader in another thread.
Yeah, the kernel loader is not some generic ELF loader thing.
> Perhaps we should be adding
> --no-warn-execstack
> wrapped in an ld-option check to KBUILD_LDFLAGS at the top level?
I think both the linker flag and the assembler flag are the "correct"
thing to do.
And yes, I don't think there is anything architecture-specific about
it, and the top-level Makefile is likely the right thing to modify.
I'm a tiny bit worried about "what versions of as/ld accept those
flags", though.
Linus
On 2022-08-08, Linus Torvalds wrote:
>On Mon, Aug 8, 2022 at 1:32 PM Nick Desaulniers <[email protected]> wrote:
>>
>> Thanks for the link; I recall Ard mentioning the ELF segments are
>> ignored by the kernels loader in another thread.
>
>Yeah, the kernel loader is not some generic ELF loader thing.
>
>> Perhaps we should be adding
>> --no-warn-execstack
>> wrapped in an ld-option check to KBUILD_LDFLAGS at the top level?
>
>I think both the linker flag and the assembler flag are the "correct"
>thing to do.
>
>And yes, I don't think there is anything architecture-specific about
>it, and the top-level Makefile is likely the right thing to modify.
>
>I'm a tiny bit worried about "what versions of as/ld accept those
>flags", though.
>
> Linus
>
If most ports don't need executable stacks, I think using `-z
noexecstack` is better than the binutils 2.39 specific
--no-warn-execstack (not recognized by lld and older GNU ld, so a
configure check will be needed).
Then -Wa,--noexecstack is not necessary: if the built relocatable files
are destined to be used with ld with -z noexecstack, the input
.note.GNU-stack sections are really redundant. It would be a difficult
story if the relocatable files can "leak" to the outside world where a
GNU ld without -z noexecstack may be used. But IMO this is not the case
for the kernel.
Users of GNU ld (BFD) from binutils 2.39+ will observe multiple
instances of a new warning when linking kernels in the form:
ld: warning: vmlinux: missing .note.GNU-stack
section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future
version of the linker
ld: warning: vmlinux has a LOAD segment with RWX permissions
Generally, we would like to avoid the stack being executable. Because
there could be a need for the stack to be executable, assembler sources
have to opt-in to this security feature via explicit creation of the
.note.GNU-stack feature (which compilers create by default) or command
line flag --noexecstack. Or we can simply tell the linker the production
of such sections is irrelevant and to link the stack as --noexecstack.
LLVM's LLD linker defaults to -z noexecstack, so this flag isn't
strictly necessary when linking with LLD, only BFD, but it doesn't hurt
to be explicit here for all linkers IMO. --no-warn-rwx-segments is
currently BFD specific and only available in the current latest release,
so it's wrapped in an ld-option check.
While the kernel makes extensive usage of ELF sections, it doesn't use
permissions from ELF segments.
Link: https://lore.kernel.org/linux-block/[email protected]/
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
Link: https://github.com/llvm/llvm-project/issues/57009
Reported-by: Jens Axboe <[email protected]>
Suggested-by: Fangrui Song <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
---
Makefile | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Makefile b/Makefile
index dc6295f91263..230e6e7679f9 100644
--- a/Makefile
+++ b/Makefile
@@ -1033,6 +1033,11 @@ KBUILD_CFLAGS += $(KCFLAGS)
KBUILD_LDFLAGS_MODULE += --build-id=sha1
LDFLAGS_vmlinux += --build-id=sha1
+KBUILD_LDFLAGS += -z noexecstack
+ifeq ($(CONFIG_LD_IS_BFD),y)
+KBUILD_LDFLAGS += $(call ld-option,--no-warn-rwx-segments)
+endif
+
ifeq ($(CONFIG_STRIP_ASM_SYMS),y)
LDFLAGS_vmlinux += $(call ld-option, -X,)
endif
--
2.37.1.559.g78731f0fdb-goog
Users of GNU ld (BFD) from binutils 2.39+ will observe multiple
instances of a new warning when linking kernels in the form:
ld: warning: arch/x86/boot/pmjump.o: missing .note.GNU-stack section
implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future
version of the linker
ld: warning: arch/x86/boot/compressed/vmlinux has a LOAD segment with
RWX permissions
Generally, we would like to avoid the stack being executable. Because
there could be a need for the stack to be executable, assembler sources
have to opt-in to this security feature via explicit creation of the
.note.GNU-stack feature (which compilers create by default) or command
line flag --noexecstack. Or we can simply tell the linker the production
of such sections is irrelevant and to link the stack as --noexecstack.
LLVM's LLD linker defaults to -z noexecstack, so this flag isn't
strictly necessary when linking with LLD, only BFD, but it doesn't hurt
to be explicit here for all linkers IMO. --no-warn-rwx-segments is
currently BFD specific and only available in the current latest release,
so it's wrapped in an ld-option check.
While the kernel makes extensive usage of ELF sections, it doesn't use
permissions from ELF segments.
Link: https://lore.kernel.org/linux-block/[email protected]/
Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107
Link: https://github.com/llvm/llvm-project/issues/57009
Reported-by: Jens Axboe <[email protected]>
Suggested-by: Fangrui Song <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
---
arch/x86/boot/Makefile | 2 +-
arch/x86/boot/compressed/Makefile | 4 ++++
arch/x86/entry/vdso/Makefile | 2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index b5aecb524a8a..ffec8bb01ba8 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -103,7 +103,7 @@ $(obj)/zoffset.h: $(obj)/compressed/vmlinux FORCE
AFLAGS_header.o += -I$(objtree)/$(obj)
$(obj)/header.o: $(obj)/zoffset.h
-LDFLAGS_setup.elf := -m elf_i386 -T
+LDFLAGS_setup.elf := -m elf_i386 -z noexecstack -T
$(obj)/setup.elf: $(src)/setup.ld $(SETUP_OBJS) FORCE
$(call if_changed,ld)
diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
index 19e1905dcbf6..35ce1a64068b 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -69,6 +69,10 @@ LDFLAGS_vmlinux := -pie $(call ld-option, --no-dynamic-linker)
ifdef CONFIG_LD_ORPHAN_WARN
LDFLAGS_vmlinux += --orphan-handling=warn
endif
+LDFLAGS_vmlinux += -z noexecstack
+ifeq ($(CONFIG_LD_IS_BFD),y)
+LDFLAGS_vmlinux += $(call ld-option,--no-warn-rwx-segments)
+endif
LDFLAGS_vmlinux += -T
hostprogs := mkpiggy
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 76cd790ed0bd..12f6c4d714cd 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -180,7 +180,7 @@ quiet_cmd_vdso = VDSO $@
sh $(srctree)/$(src)/checkundef.sh '$(NM)' '$@'
VDSO_LDFLAGS = -shared --hash-style=both --build-id=sha1 \
- $(call ld-option, --eh-frame-hdr) -Bsymbolic
+ $(call ld-option, --eh-frame-hdr) -Bsymbolic -z noexecstack
GCOV_PROFILE := n
quiet_cmd_vdso_and_check = VDSO $@
--
2.37.1.559.g78731f0fdb-goog
Users of GNU ld (BFD) from binutils 2.39+ will observe multiple
instances of a new warning when linking kernels in the form:
ld: warning: vmlinux: missing .note.GNU-stack
section implies executable stack
ld: NOTE: This behaviour is deprecated and will be removed in a future
version of the linker
ld: warning: vmlinux has a LOAD segment with RWX permissions
Generally, we would like to avoid the stack being executable. Because
there could be a need for the stack to be executable, assembler sources
have to opt-in to this security feature via explicit creation of the
.note.GNU-stack feature (which compilers create by default) or command
line flag --noexecstack. Or we can simply tell the linker the production
of such sections is irrelevant and to link the stack as --noexecstack.
LLVM's LLD linker defaults to -z noexecstack, so this flag isn't
strictly necessary when linking with LLD, only BFD, but it doesn't hurt
to be explicit here for all linkers IMO. --no-warn-rwx-segments is
currently BFD specific and only available in the current latest release,
so it's wrapped in an ld-option check.
While the kernel makes extensive usage of ELF sections, it doesn't use
permissions from ELF segments.
Broken up into 2 patches; one for the top level vmlinux, one x86
specific since a few places in the x86 build reset KBUILD_LDFLAGS.
Nick Desaulniers (2):
Makefile: link with -z noexecstack --no-warn-rwx-segments
x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments
Makefile | 5 +++++
arch/x86/boot/Makefile | 2 +-
arch/x86/boot/compressed/Makefile | 4 ++++
arch/x86/entry/vdso/Makefile | 2 +-
4 files changed, 11 insertions(+), 2 deletions(-)
base-commit: 15205c2829ca2cbb5ece5ceaafe1171a8470e62b
--
2.37.1.559.g78731f0fdb-goog
On 8/10/22 4:24 PM, Nick Desaulniers wrote:
> Users of GNU ld (BFD) from binutils 2.39+ will observe multiple
> instances of a new warning when linking kernels in the form:
>
> ld: warning: vmlinux: missing .note.GNU-stack
> section implies executable stack
> ld: NOTE: This behaviour is deprecated and will be removed in a future
> version of the linker
> ld: warning: vmlinux has a LOAD segment with RWX permissions
>
> Generally, we would like to avoid the stack being executable. Because
> there could be a need for the stack to be executable, assembler sources
> have to opt-in to this security feature via explicit creation of the
> .note.GNU-stack feature (which compilers create by default) or command
> line flag --noexecstack. Or we can simply tell the linker the production
> of such sections is irrelevant and to link the stack as --noexecstack.
>
> LLVM's LLD linker defaults to -z noexecstack, so this flag isn't
> strictly necessary when linking with LLD, only BFD, but it doesn't hurt
> to be explicit here for all linkers IMO. --no-warn-rwx-segments is
> currently BFD specific and only available in the current latest release,
> so it's wrapped in an ld-option check.
>
> While the kernel makes extensive usage of ELF sections, it doesn't use
> permissions from ELF segments.
>
> Broken up into 2 patches; one for the top level vmlinux, one x86
> specific since a few places in the x86 build reset KBUILD_LDFLAGS.
For x86-64:
Tested-by: Jens Axboe <[email protected]>
--
Jens Axboe
On Wed, Aug 10, 2022 at 3:25 PM Nick Desaulniers
<[email protected]> wrote:
>
> Broken up into 2 patches; one for the top level vmlinux, one x86
> specific since a few places in the x86 build reset KBUILD_LDFLAGS.
I've applied these to my tree directly, since I was doing the "fix up
the i386 crypto build error with gcc-12.1" work anyway, and this was
kind of in the same vein.
I want to put the "random tool versions cause build problems" issues
behind us before doing the rc1 thing this weekend.
Those were the two issues on my radar - I'm assuming there are others,
but I can't think of any right now.
Linus