Basically yes, however if you build gcc yourself or via buildroot you can change the default behaviour to emit that to GNU ld by default. Which should be the preferred way but alas it might break some applications like a JIT (e.g. luajit), luckily there is '-z execstack' for those cases.
There might be things about the FPU-stuff I forgot, but I did backport that stuff to v3.10.108 a year ago. I recommend reading these papers: https://cyber-itl.org/2018/12/07/a-look-at-home-routers-and-linux-mips.html and I would say it is applicable to ARM, PPC etc as well. I also recommend running https://github.com/slimm609/checksec.sh (depends on the 'readelf' binary) on your romfs to check that the binaries has got these security mitigations enabled. //M Sent from my BlackBerry - the most secure mobile device Original Message From: [email protected] Sent: April 30, 2020 05:55 To: [email protected]; [email protected]; [email protected] Subject: Re: Kernel warns of executable stack So just to summarize (i.e. this is what I'm about to include as the commit message that sets the flags in our build system). Prior to https://lore.kernel.org/lkml/20141004030438.28569.85536.stgit@linux-yegoshin/ floating point emulation for Linux MIPS required the stack to be executable. Modern kernels don't require this and as of v5.6 a warning is issued. But for backwards compatibility the toolchains still use an executable stack for MIPS unless explicitly told not to. Passing -z noexecstack to GNU ld tells it not to use an executable stack. On 30/04/20 2:26 pm, Markus Gothe wrote: > Depends if you use LDFLAGS or CFLAGS actually; -Wl,-z,noexecstack is the full > syntax for the latter which I thought you were referring too. > > //M > > Sent from my BlackBerry - the most secure mobile device > > > Original Message > > > From: [email protected] > Sent: April 30, 2020 04:15 > To: [email protected]; [email protected]; [email protected] > Subject: Re: Kernel warns of executable stack > > > Just to aid future mailing list searchers > > The correct setting is "-z noexecstack" putting it in my targets default > CFLAGS seems to have done the trick. I haven't seen any adverse effect > of this (yet). > > https://gcc.gnu.org/onlinedocs/gcc-8.3.0/gcc/Link-Options.html#index-z > > On 30/04/20 12:11 pm, Markus Gothe wrote: >> You need to rebuild the toolchain's libc as well. >> >> For hardening I also suggest fixing RELRO and BIND_NOW. >> >> //M >> >> Sent from my BlackBerry - the most secure mobile device >> >> >> Original Message >> >> >> From: [email protected] >> Sent: April 30, 2020 02:00 >> To: [email protected]; [email protected]; [email protected] >> Subject: Re: Kernel warns of executable stack >> >> >> >> On 24/04/20 10:54 am, Markus Gothe wrote: >>> It's not required per se for an application. >>> >>> But you would need to relink your binaries with '-z,noexecstack' to turn >>> it off. >>> >>> //M >> So I've been trying to set CONFIG_EXTRA_LDFLAGS="-z,noexecstack" in my >> .config but it doesn't seem to make it through to the final link >> command. Is CONFIG_EXTRA_LDFLAGS expected to work? >> >>> On 2020-04-24 00:25, Chris Packham wrote: >>>> On Fri, 2020-04-24 at 00:08 +0200, Markus Gothe wrote: >>>>> Background: The executable stack is needed for MIPS and the FPU >>>>> (which >>>>> decodes any unknown instruction as well). >>>>> >>>>> There have been some patches floating around to fix this behavior >>>>> since >>>>> Linux 3.12 so probably that's why you didn't notice before upgrading. >>>>> >>>>> The 'dc' applet at least requires an executable stack and might be >>>>> why >>>>> it is triggered. (Did get a MIPS32-kernel to go crash with 'bad >>>>> stack' >>>>> when running dc -e '4 0 / p' however it's fixed in 1.31.0). >>>>> >>>>> //M >>>> OK and I can confirm that I do get the error message on mips64 and >>>> mips32 (I just failed to notice in my automated test output). >>>> >>>> So executable stack is required for floating point on mips? Should I >>>> send a kernel patch to add && !IS_ENABLED(CONFIG_MIPS) to the warning? >>>> >>>>> On 2020-04-23 23:39, Chris Packham wrote: >>>>>> On Thu, 2020-04-23 at 07:29 +0200, Christophe Leroy wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Christophe >>>>>>> >>>>>>> Le 23/04/2020 à 03:13, Chris Packham a écrit : >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm just in the process of updating our products to Linux v5.6 >>>>>>>> and >>>>>>>> one >>>>>>>> of them produces a new warning message from the kernel about >>>>>>>> busybox >>>>>>>> (v1.31.1) >>>>>>>> >>>>>>>> kernel: process '/bin/busybox' started with executable stack >>>>>>> Got similar discussion about klibc 2 monthes ago, look at >>>>>>> https://lists.zytor.com/archives/klibc/2020-February/004271.html >>>>>>> >>>>>>>> The target in question is a mips64 (octeon3). We have other >>>>>>>> targets >>>>>>>> (mips32, armv7, ppc32, ppc64) which don't complain. >>>>>>>> >>>>>>>> Some searching led me to >>>>>>>> >>>>>>>> https://lore.kernel.org/lkml/20191208171918.GC19716@avx2/ >>>>>>>> >>>>>>>> Which suggests I should be filing a bug report with the vendor >>>>>>>> so >>>>>>>> here >>>>>>>> I am. >>>>>>> Did you have a look into busybox bugzilla ? >>>>>>> https://bugs.busybox.net/ >>>>>> I did a quick search of the mailing list didn't spot anything >>>>>> yesterday. >>>>>> >>>>>> Just now I did find https://bugs.busybox.net/show_bug.cgi?id=12801 >>>>>> which is in the ball-park. It points at uclibc + binutils 2.31. I'm >>>>>> using GNU libc and binutils 2.32. >>>>>> >>>>>>>> Here's some readelf output from the binary >>>>>>> Can you perform "objdump -x " on your binary ? >>>>>>> >>>>>> The output is quite large so I'll link to it instead of including >>>>>> it >>>>>> in-line. >>>>>> >>>>>> https://gist.github.com/cpackham/48eeab4b8801a57ef737e3fda265cae7 >>>>>> >>>>>> Interestingly I can't see anything rwx or RWE in either output >>>>>> >>>>>> _______________________________________________ >>>>>> busybox mailing list >>>>>> [email protected] >>>>>> http://lists.busybox.net/mailman/listinfo/busybox _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
