Re: [Qemu-devel] [PATCH] oslib-posix: New qemu_alloc_stack() to allocate stack with correct perms

[Richard Henderson]

On 06/17/2016 09:36 AM, Peter Maydell wrote:
> On 17 June 2016 at 17:12, Richard Henderson <address@hidden> wrote:
>> What about using dl_iterate_phdr, looking for PT_GNU_STACK?
>> That interface is present on a few other hosts besides Linux.
> 
> We could do that. I note that the MIPS kernel is buggy in that
> it will assume the stack is executable even if the binary
> has PT_GNU_STACK saying "please don't be executable". 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.

>> 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.


r~