Kernel warns of executable stack

[Markus Gothe]

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 at alliedtelesis.co.nz
Sent: April 30, 2020 04:15
To: nietzsche at lysator.liu.se; christophe.leroy at c-s.fr; busybox at 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 at alliedtelesis.co.nz
> Sent: April 30, 2020 02:00
> To: nietzsche at lysator.liu.se; christophe.leroy at c-s.fr; busybox at 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 at busybox.net
>>>>> http://lists.busybox.net/mailman/listinfo/busybox