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
