Re: [Qemu-devel] [PATCH 1/6] oslib-posix: add helpers for stack alloc and free

[Paolo Bonzini]

On 04/07/2016 08:18, Peter Lieven wrote:
> Am 01.07.2016 um 22:49 schrieb Richard Henderson:
>> On 07/01/2016 01:12 PM, Richard Henderson wrote:
>>> On 06/30/2016 12:37 AM, Peter Lieven wrote:
>>>> +void *qemu_alloc_stack(size_t sz)
>>>> +{
>>>> +    /* allocate sz bytes plus one extra page for a guard
>>>> +     * page at the bottom of the stack */
>>>> +    void *ptr = mmap(NULL, sz + getpagesize(), PROT_NONE,
>>>> +                     MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>>>> +    if (ptr == MAP_FAILED) {
>>>> +        abort();
>>>> +    }
>>>> +    if (mmap(ptr + getpagesize(), sz, PROT_READ | PROT_WRITE,
>>>> +        MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, -1, 0) ==
>>>> MAP_FAILED) {
>>>> +        abort();
>>>> +    }
>>
>> Rare platforms now, but fwiw, this is incorrect for hppa and ia64.
>>
>> For hppa, stack grows up, so the guard page needs to be at the top.
>>
>> For ia64, there are two stacks, the "normal" program stack (grows
>> down) and the register window stack (grows up).  The guard page goes
>> in between.
>>
>> See e.g. glibc/nptl/allocatestack.c
>>
>> #ifdef NEED_SEPARATE_REGISTER_STACK
>>           char *guard = mem + (((size - guardsize) / 2) & ~pagesize_m1);
>> #elif _STACK_GROWS_DOWN
>>           char *guard = mem;
>> #elif _STACK_GROWS_UP
>>           char *guard = (char *) (((uintptr_t) pd - guardsize) &
>> ~pagesize_m1);
>> #endif
>>           if (mprotect (guard, guardsize, PROT_NONE) != 0)
> 
> It seems that ia64 needs even more care when allocating a stack, right?

No, you just pass the stack and the runtime takes care of initializing
the two stack pointers:

    uc.uc_link = &old_uc;
    uc.uc_stack.ss_sp = co->stack;
    uc.uc_stack.ss_size = stack_size;
    uc.uc_stack.ss_flags = 0;

FWIW, I've heard about some experiments with "split" stacks on x86 too.
In this case variables that escaped went on the "grows up" part, while
everything else (parameters, spills and call return addresses) stayed on
the hardware "grows down" part.  The result is more secure and actually
even faster because of better TLB locality.

Paolo

> Would you think it is ok to only handle _STACK_GROWS_DOWN and
> _STACK_GROWS_UP ?
> 
> Peter