Paul Burton <Paul.Burton@xxxxxxxxxx> writes: > 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? We are/were under the assumption that a pre-existing kernel will honor the PT_GNU_STACK marker overriding the arch specific read-implies-exec logic: http://lxr.free-electrons.com/source/fs/binfmt_elf.c?v=3.2#L689 http://lxr.free-electrons.com/source/fs/exec.c?v=3.2#L703 This means that if we produce tools which have PT_GNU_STACK with executable stack disabled then older kernels will crash as they will obey it and the FPU emulator will break. Is this incorrect? I.e. does today's MIPS kernel do absolutely nothing when PT_GNU_STACK is seen? The "AV_FLAGS_MIPS_GNU_STACK" is a proposal of how to handle the transition from a kernel that does as I describe above to one that safely supports no-exec-stack. I don't know if this has to be an AT_FLAGS or whether a HWCAP would do. I think we perhaps latched on to the idea of AT_FLAGS as we have used that as part of the nan2008 work but we can work through that detail later. The user-mode work is still very much in review. There is no kernel with this feature yet. Faraz: Did I explain that correctly? Matthew
