[prev in list] [next in list] [prev in thread] [next in thread]
List: busybox
Subject: Re: Kernel warns of executable stack
From: Chris Packham <Chris.Packham () alliedtelesis ! co ! nz>
Date: 2020-04-30 5:00:00
Message-ID: 0896eb5d-a3d3-35f6-f540-a5c3646e4765 () alliedtelesis ! co ! nz
[Download RAW message or body]
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: Chris.Packham@alliedtelesis.co.nz
> Sent: April 30, 2020 05:55
> To: nietzsche@lysator.liu.se; christophe.leroy@c-s.fr; busybox@busybox.net
> 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: Chris.Packham@alliedtelesis.co.nz
> > Sent: April 30, 2020 04:15
> > To: nietzsche@lysator.liu.se; christophe.leroy@c-s.fr; busybox@busybox.net
> > 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: Chris.Packham@alliedtelesis.co.nz
> > > Sent: April 30, 2020 02:00
> > > To: nietzsche@lysator.liu.se; christophe.leroy@c-s.fr; busybox@busybox.net
> > > 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
> > > > > > > busybox@busybox.net
> > > > > > > http://lists.busybox.net/mailman/listinfo/busybox
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic