Skip to contentSkip to conversation

New: Flag '-Wa, --noexecstack' is missing when building uclibc with newer binutils

Buildroot bugzilla at busybox.net 1 participant 7 messages Apr 22, 2020 – Apr 24, 2020

lore
Share & tools
lore
#0 lore raw

https://bugs.busybox.net/show_bug.cgi?id=12801

Bug ID: 12801
Summary: Flag '-Wa,--noexecstack' is missing when building
uclibc with newer binutils
Product: buildroot
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P5
Component: Other
Assignee: unassigned at buildroot.uclibc.org
Reporter: m.patzlaff at pilz.de
CC: buildroot at uclibc.org
Target Milestone: ---

Created attachment 8436
--> https://bugs.busybox.net/attachment.cgi?id=8436&action=edit
defconfig to reproduce the issue

When I upgraded buildroot from 2019.02.8 to 2020.02 and re-build my configuration I noticed that all binaries (executables and shared libraries) have the executable stack requested in the GNU_STACK program header. I did some research and also tried to narrow the cause. Eventually I found this:

\ |
binutils \ uclibc | 1.0.31 | 1.0.32
------------------+-----------+---------------

2.30              | fine      | fine
2.31.1            | execstack | execstack
2.32              | execstack | execstack
2.33.1            | execstack | execstack

So, until binutils 2.30 everything goes fine. Regardless of what GCC version (I tested with 4.9 and 8.3.0) I used, the uclibc libraries were marked with non-executable stack and thus all other binaries were OK too. But starting from binutils 2.31.1 something goes wrong. In the log for binutils 2.30 + uclibc 1.0.31 one can see, that the flag "-Wa,--noexecstack" is properly passed to the compiler. In the log for binutils 2.32 + uclibc 1.0.32 this flag is missing. And here is where I am lost. I can't figure out why because executing the flag detection in Rules.mak from uclibc manually returns the correct result. And I also double checked the security options in uclibc-menuconfig.

To reproduce the results above it's best to use the attached defconfig on buildroot versions 2019.02.8 and 2020.02.

Signature · 2 lines
You are receiving this mail because:
You are on the CC list for the bug.
#2 lore raw

[Buildroot] [Bug 12801] Flag '-Wa, --noexecstack' is missing when building uclibc with newer binutils

In reply to bugzilla at busybox.net

https://bugs.busybox.net/show_bug.cgi?id=12801

--- Comment #2 from Marcel Patzlaff <[email protected]> --- Created attachment 8446
--> https://bugs.busybox.net/attachment.cgi?id=8446&action=edit
Partial log of the failure case

Signature · 2 lines
You are receiving this mail because:
You are on the CC list for the bug.
#3 lore raw

[Buildroot] [Bug 12801] Flag '-Wa, --noexecstack' is missing when building uclibc with newer binutils

In reply to bugzilla at busybox.net

https://bugs.busybox.net/show_bug.cgi?id=12801

Marcel Patzlaff <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

                 OS|Linux                       |All
             Target|                            |ARM Cortex A9
              Build|                            |x86_64 laptop
           Hardware|PC                          |All
Signature · 2 lines
You are receiving this mail because:
You are on the CC list for the bug.
#4 lore raw

[Buildroot] [Bug 12801] Flag '-Wa, --noexecstack' is missing when building uclibc with newer binutils

In reply to bugzilla at busybox.net

https://bugs.busybox.net/show_bug.cgi?id=12801

Marcel Patzlaff <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

            Product|buildroot                   |uClibc
          Component|Other                       |Other
           Assignee|unassigned at buildroot.uclibc |unassigned at uclibc.org
                   |.org                        |
                 CC|                            |uclibc-cvs at uclibc.org

--- Comment #3 from Marcel Patzlaff <[email protected]> ---
I finally found what the problem is. The check_as macro in uclibc/Rules.mak does not function with newer binutils versions anymore. Executing the check manually yield:

$ /opt/debug/buildroot_toolchain/usr/bin/arm-se-linux-uclibcgnueabihf-gcc
-Wa,--noexecstack -Wa,-Z -c -o /dev/null -xassembler /dev/null || echo "WTF"

Assembler messages:
Fatal error: The input '/dev/null' and output '/dev/null' files are the same

So basically, this seems to be uClibc bug.

Signature · 2 lines
You are receiving this mail because:
You are on the CC list for the bug.
#5 lore raw

[Buildroot] [Bug 12801] Flag '-Wa, --noexecstack' is missing when building uclibc with newer binutils

In reply to bugzilla at busybox.net

https://bugs.busybox.net/show_bug.cgi?id=12801

romain.naour at gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at uclibc.org |wbx at openadk.org

--- Comment #4 from romain.naour at gmail.com ---
Hi Marcel,

I'm able to reproduce the issue.

Indeed the error message come from a new as check from binutils 2.31.x series:

https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=67f846b59b32f3d704c601669409c2584383fea9

See similar report and kernel commit:
https://lkml.org/lkml/2018/8/9/233

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=e9666d10a5677a494260d60d1fa0b73cc7646eb3

I'm adding Waldemar in Cc of this bug.

Best regards,
Romain

Signature · 2 lines
You are receiving this mail because:
You are on the CC list for the bug.
#6 lore raw

[Buildroot] [Bug 12801] Flag '-Wa, --noexecstack' is missing when building uclibc with newer binutils

In reply to bugzilla at busybox.net

https://bugs.busybox.net/show_bug.cgi?id=12801

--- Comment #5 from Marcel Patzlaff <[email protected]> --- Created attachment 8451
--> https://bugs.busybox.net/attachment.cgi?id=8451&action=edit
Patch to fix the check_as Makefile macro.

Please find a possible patch attached to fix this. I will also push it to the buildroot mailinglist, as the problem should be fixed really soon.

Signature · 2 lines
You are receiving this mail because:
You are on the CC list for the bug.