Paul, You wrote: > 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. however IIUC this is inaccurate to say the least I'm afraid, as generic PT_GNU_STACK support went in to binutils with: commit 04c3a75556c018feb1f609404c627414a7ef672e Author: Nathan Sidwell <nathan@xxxxxxxxxxxxxxxx> Date: Tue Oct 23 09:33:56 2012 +0000 <https://sourceware.org/ml/binutils/2012-10/msg00317.html>, ("cleanup PT_GNU_STACK size handling"), replacing an earlier target-specific implementation previously present, and the MIPS port specifically has been updated to actually report this at the EI_ABIVERSION offset of the `e_ident' array of the ELF header with commit 17733f5be961 ("Increment the ABIVERSION to 5 for MIPS objects with non-executable stacks."), earlier this year (it's not clear to me offhand why we need to do this rather than relying on the lone presence of PT_GNU_STACK, but I'm sure someone will enlighten me). By the time this kernel update hits the street I expect we'll have this feature present in a proper binutils release even as 2.27 is currently being rolled out already. Have I missed anything? Maciej
