Re: [RFC PATCH v3 2/2] MIPS: non-exec stack & heap when non-exec PT_GNU_STACK is present

[Paul Burton <paul.burton@imgtec.com>]

On 30/06/16 10:25, Matthew Fortune wrote:
> Paul Burton <Paul.Burton@imgtec.com> writes:
>> The stack and heap have both been executable by default on MIPS until
>> now. This patch changes the default to be non-executable, but only for
>> ELF binaries with a non-executable PT_GNU_STACK header present. This
>> does apply to both the heap & the stack, despite the name PT_GNU_STACK,
>> and this matches the behaviour of other architectures like ARM & x86.
>>
>> Current MIPS toolchains do not produce the PT_GNU_STACK header, which
>> means that we can rely upon this patch not changing the behaviour of
>> existing binaries. The new default will only take effect for newly
>> compiled binaries once toolchains are updated to support PT_GNU_STACK,
>> and since those binaries are newly compiled they can be compiled
>> expecting the change in default behaviour. Again this matches the way in
>> which the ARM & x86 architectures handled their implementations of
>> non-executable memory.
>
> There will be some extra work on top of this to inform user-mode that
> no-exec-stack support is actually safe. I'm a bit fuzzy on the exact
> details though as I have not been directly involved for a while.
>
> https://www.sourceware.org/ml/libc-alpha/2016-01/msg00719.html
>
> Adding Faraz who worked on the user-mode side and Maciej who has been
> reviewing.

Hi Matthew,

Interesting. That glibc patch seems to imply that the kernel already 
supports this, which isn't true. It makes use of a 
"AV_FLAGS_MIPS_GNU_STACK" constant & says that's taken from Linux, but 
it doesn't exist. Are you using an experimental patch for the kernel 
side (perhaps Leonid's?). I'm not sure why you'd use AT_FLAGS for this, 
which Linux currently unconditionally sets to 0 for all architectures. 
Would a HWCAP bit for RIXI perhaps be more suitable?

Thanks,
     Paul