Kernel warns of executable stack

[Markus Gothe]

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