On 30/06/16 10:25, Matthew Fortune wrote:
Paul Burton <Paul.Burton@xxxxxxxxxx> 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
