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
