On 30/04/20 4:23 pm, Markus Gothe wrote: > 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.
We're using crosstool-NG. There's not an explicit config item for it (there is for relro) but there's a catch-all for extra config for binutils. Next time we re-spin the toolchain I'll look at making it the default. > There might be things about the FPU-stuff I forgot, but I did backport that > stuff to v3.10.108 a year ago. Yeah I think the link I turned up never actually landed but patches in a similar vein over a longer period did. > 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. Thanks for the links. I'll look into them. > //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
