[PATCH v2 2/3] nptl: Add libc allocated shadow stack for new threads

[Adhemerval Zanella Netto]

On 05/09/25 14:55, Mark Brown wrote:
> On Fri, Sep 05, 2025 at 02:22:46PM -0300, Adhemerval Zanella Netto wrote:
> 
>> So what is the advantage of extending clone3 to accept a map_shadow_stack
>> stack if the idea is to not allow user re-use the allocated shadow guard
>> region and forcing it to always deallocate it after thread finishes?
> 
> It is possible to switch between shadow stacks at runtime with no kernel
> intervention, if a userspace is doing that then there is no guarantee
> that the shadow stack in use at the time the thread exits is the same
> one that the thread was started with.  Potentially a thread will be
> started with a stack that was previously in use in another context.  You
> either end up with userspace having to deallocate stacks when they're
> finished with or having the kernel always allocate a stack and userspace
> pivot off that if it wants something else.

But this is not the usual programming mode for pthread code, and in places
glibc does it (makecontext) it leaks the allocate shadow stack anyway.  I
can't not say much what other runtime might do wrt shadow stack management,
or if users will mess with stack pointer along with pthread; but in either
cases it seems that the shadow stack management is out of scope of the C
runtime.

So maybe if clone3 just allows to setup the expected shadow stack size instead
of requiring C runtime to manage the shadow stack itself would be a 
more straightforward interface to use along pthread.

> 
>> Wouldn't it be simpler to extend clone3 with a preferred guard size instead,
>> an let the kernel allocate/deallocate the shadow guard region instead?
> 
> I'm not sure what you mean when you're talking about "guard" here, are
> you just taking about the shadow stack there or some additional guard
> region around it?

Sorry, I meant the shadow stack (I though using the terms
Documentation/arch/arm64/gcs.rst uses would be more clear).