[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH] oslib-posix: New qemu_alloc_stack() to allocate stack with correct perms
Date: Fri, 17 Jun 2016 18:32:15 +0100

On 17 June 2016 at 18:27, Richard Henderson <address@hidden> 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.

-- PMM

reply via email to

[Prev in Thread] Current Thread [Next in Thread]