Re: [PATCH 3/3] Misc: Add <sys/cstack.h> and the cstack_* family of functions

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 24/05/2021 11:58, Bruno Haible wrote:
> In reply to <https://sourceware.org/pipermail/libc-alpha/2021-May/126608.html>:
> 
>> These functions are expected to be used with sigaltstack and
>> coroutines.
> 
> What is the added value of these functions, compared to what existing
> programs already do?
> 
> I did a small survey of how a couple of single-threaded programs allocate
> their alternate stack:
>   - The majority allocate it statically.
>   - Some use malloc().
>   - Some use mmap().
>   - Some use alloca(), i.e. a portion of the already-allocated stack in
>     the program's main() function.
> The size that these programs use are:
>   - some use SIGSTKSZ,
>   - some use 16 KiB,
>   - some use 64 KiB.
> 
> We know that 16 KiB is too small on some platforms, and that a static
> allocation of SIGSTKSZ bytes leads to a compilation error now.
> 
> Therefore the implemented added value is:
> 
>   * The ability to use SIGSTKSZ without a compilation error.
> 
> Other added value that would be useful in some cases are:
> 
>   * The ability to have a guard page at the stack top.
>     This is half implemented. IMO an mprotect (.., top_guard_size, PROT_NONE)
>     is missing after the __mmap call.
> 
>   * The ability to have a guard page at the stack bottom.
>     This too is half implemented. IMO an mprotect (.., bottom_guard_size, PROT_NONE)
>     is missing after the __mmap call.

I think both point are resolved in the v2 [1]

> 
>   * A verification that the allocated size is not larger than
>     getrlimit(RLIMIT_STACK). If the system or the user has set a maximum
>     stack size of, say, 8 MB, should the program be able to allocate a
>     stack of 1 GB size, in this way?

My vier is this is similar to users provides pthread_attr_setstack. The
RLIMIT_STACK is useful to define *default* values, I don't see much gain
in enforcing it on this API that does not correlate directly with it.

> 
>   * Support for GCC nested functions, when they need an executable stack.
>     GCC, binutils, and glibc/nptl/allocatestack.c go to great lengths to
>     support this, even from dynamically loaded shared libraries. (See the
>     attached test cases.) It is poor if this facility does not support it.

This is explicit stated on the documentation Florian has added on the v2 of
this patchset:

| Allocated stacks are not explicitly allocated with executable memory
| even if the current process image uses an executable stack.  The
| stacks can still be executable for other reasons, e.g., lack of
| hardware support for non-executable stacks.

I think we should make non-executable stack as default, the nested function
requirement is a security can of worms and if user really want they can
mprotect the required stack explicit. 

If this is really a requirement, I think the best options would be to add
an extra flag to opt-in.

> 
>   * Automatic deallocation when the current thread exits.
>     In those cases where a thread allocated a cstack_t for its own use,
>     it is welcome if it can say "clean it up automatically when the thread
>     exits". Otherwise some programmers will still prefer the "use alloca()"
>     approach, which has this automatic cleanup property.

The cstack_t is basically another heap object and I think it should be
handled as such.  

And I think pthread_attr_setstacksize fits what your are describing,
minus the guard page for *both* ends.

> It would be useful to have this feature on the thread stacks, in the
> first place. That is, add some pthread_attr_setbottomguard() function
> to <pthread.h> that allows the application to enable this for the
> thread stacks.

We might need another API to set the bottom guard size as well, and
maybe depending of the architecture enabled it by default (for 64-bit
as least).  It might occur in some extra overhead, specially on aarch64
witch sets the ARCH_MIN_GUARD_SIZE as 64k.

> 
> Bruno
> 

[1] https://patchwork.sourceware.org/project/glibc/list/?series=2208