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

[Peter Lieven <pl@kamp.de>]

Am 04.07.2016 um 12:19 schrieb 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.

So, you would basically copy the if/elif part from allocatestack.c ?

In this case I would also count the guardpage as part of the stack, so
that the usable stack size is actually reduced by one page?

Peter