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

[Mark Brown]

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.

> 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20250905/3cdc862b/attachment.sig>