On 17 June 2016 at 18:27, Richard Henderson <r...@twiddle.net> wrote: > On 06/17/2016 09:36 AM, Peter Maydell wrote: >> And >> most architectures except x86-64 won't honour PT_GNU_STACK=non-exec >> unless the parent process also had nonexec stack (because they >> let the READ_IMPLIES_EXEC personality flag be inherited; see >> https://insights.sei.cmu.edu/cert/2014/02/feeling-insecure-blame-your-parent.html >> ). So the PT_GNU_STACK flag doesn't necessarily match up with >> either the actual executability of the standard stack or with >> what the kernel actually requires. > > How bizarre. > > Glibc will most definitely honour PT_GNU_STACK when allocating thread stacks, > so it's a weird thing for the kernel to want to inherit for the initial thread > stack.
I agree. I think it's a bug in the non-x86-64 architectures (and particularly annoying if /sbin/init happens to not be marked as being ok for non-exec stack). >>> But really this is a place that I'd much rather fall back to an ifdef ladder >>> than assume executable permission is required. >> >> The trouble with this is that it means that as and when the MIPS >> folks fix their kernel and libc and compiler to support non-exec >> stacks we won't automatically pick this up, and our stacks will >> remain executable. Also it requires us to audit every architecture >> to find out which ones require exec-stack. But maybe it is just >> MIPS? (Maybe we could just say "this is a MIPS kernel bug" ? :-)) > > I am inclined to hope that this is just a mips thing. > It's a pretty strange situation. > > But I did really mean fall back. Yes, try the other methods, but > if we don't detect anything about the stack, only enable it via > ifdef ladder. Oh, I see. thanks -- PMM
