How can I fix "/usr/bin/ld: warning: trap.o: missing .note.GNU-stack section implies executable stack"?

Question

I compiled the same project on ubuntu20.04 in wsl and my main used OS archLinux respectively. On wsl, everything went normal, while on archlinux the error message as follows would show:

/usr/bin/ld: warning: trap.o: missing .note.GNU-stack section implies executable stack
/usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker

It seems like a error caused by the linker ld, the version message of it on my linux os is:

GNU ld (GNU Binutils) 2.39
Copyright (C) 2022 Free Software Foundation, Inc.

And it on my wsl is:

GNU ld (GNU Binutils for Ubuntu) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.

On arch, gcc's version is 12.1.1, while on wsl it is gcc 9.3.0

Was it caused by the difference between the old and new versions? How can I fix it?

Inveracity

On arch, gcc's version is 12.1.1, while on wsl it is gcc 9.3.0 – Inveracity

Is this your project or someone else's? The answer is going to be different depending on whether you want your program to execute from the stack. My crystal ball says the project manually removes that stack section before linking? But without the project, we can only speculate. – Alithia

A possible way to fix it is to install 9.3.0 on arch, and compile with that version instead. – Alithia

Actually, it was not my project. So did you mean that it mostly caused by the version of compilers? The link is github.com/NJU-ProjectN/fceux-am. Unfortunately, it only has Chinese documents. – Inveracity

I don't see a file named trap in that project. Where does trap.o come from? – Alithia

Sorry, seems like this project is related with this one github.com/NJU-ProjectN/abstract-machine, I found trap in the abstract-machine/am/build/native/src/native directory. – Inveracity

No idea. Looks like a standard "this will be deprecated in future gcc versions" warning. trap.o is being generated without a GNU-stack note, and the old default behavior was that this allows an executable stack. The newer default behavior will be that this prevents an executable stack. So program behavior could change in future versions. Looks like it's not easy to disable linker warnings. If you want to explicitly add a GNU-stack note with -execstack or no-execstack that would fix it. Try no-execstack first and see if that leads to a segfault. – Alithia

I tried both, added them in the Makefile of fceux-am, seems like it doesn't make any difference. The same message is shown. Did I do anything wronG? – Inveracity

I have no idea if you did anything wrong. The project is too complex for me to analyze it and I'm not a linker expert. I don't even know if that's the correct place to put those compiler commands. Inspect trap.o. Did the generated trap.o function include the .notes.GNU-stack line? If not, then the compiler flag did nothing. Does the Makefile in fceux-am have anything to do with compiling trap.o? – Alithia

I found the right place to insert those flags. Here's the thing, when I use no-execstack, /usr/bin/ld: warning: -z no-execstack ignored this will be shown; while using execstack, nothing include the linker warning was shown. So I guess this is it? – Inveracity

Sounds good to me. Ship it. Again, not a linker expert. – Alithia

thanks a lot! You’re definitely an expert to me. – Inveracity

Now my worry is that if you're explicitly adding execstack to your compilation, your program's stack is now executable. That's a security issue. I'd rather have the warning on linking than the security issue forever. – Alithia

Answer 1

Call with ld option -z noexecstack.

Credit to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136.

Handyman

Answer 2

This is a new warning message introduced by GNU bin-utils version 2.39.

Here is quotation from the release message:

The ELF linker will now generate a warning message if the stack is made executable. Similarly it will warn if the output binary contains a segment with all three of the read, write and execute permission bits set. These warnings are intended to help developers identify programs which might be vulnerable to attack via these executable memory regions.

That being said, it is difficult to tell why your code would produce an executable stack. Here is a list of possible causes and solutions:

• When linking (or compiling and linking at the same time), pass the flag -z noexecstack to gcc or clang to forcefully disable executable stack, if plausible.
• If your project contains raw x86-64 assembly code, you may need to add the following line in the assembly .section .note.GNU-stack,"",@progbits. This line tells the compiler not to use executable stack;
• If you have written assembly code that explicit employs an executable stack, you shall pass the flag -z execstack when linking. This flag disables the warning. It would be noted that an executable stack is generally considered a security vulnerability;
• The trickiest part is that although you have no desire of an executable stack, the compiler somehow deems it necessary. One possible causation (among many other) is nested function and function pointers. It is hard to spot these incidences; one method may be compiling all the file into assembly and spot for .section .note.GNU-stack,"x",@progbits, which implies the use of executable stack. In such cases passing the flag -z noexecstack would not suffice. Although the warning is suppressed and probably compilation and linking would success, runtime errors are likely to ensue.

Tonkin

In the last case, where you absolutely do want executable stacks but you don't want the message, you can pass an option to gcc: -Wl,--no-warn-execstack worth saying, perhaps, that security minded folks recommend not using executable stacks which is of course why the warning has been added. So much for code is data and data is code. – Interbedded

Answer 3

If you're using cmake, you can add this one.

set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -z noexecstack")

Prudenceprudent