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

[Mark Brown]

On Wed, Sep 17, 2025 at 11:27:18AM -0300, Adhemerval Zanella Netto wrote:

[Your mail is a bit hard to read due to being more than 80 columns wide]

> But what is the point in adding composability (map_shadow_stack) on clone3, when the 
> expected usage does not allow the reuse of the previously allocated shadow stack and 
> forces the userland to manually manage and always deallocate the shadow stack when 
> the thread finishes?

The main things are control of the stack placement and size, and the
green threads cases.

> The runtime flexibility could make sense in a runtime where green-threads are 
> first-order primitives, where it exchanges the stack of the underlying OS threads 
> depending on the workload. However, for the C runtime (and I believe for many other 
> runtimes as well), and more specifically, pthread, it would be much simpler if 
> userland could simply specify the shadow stack size. Even for C++ coroutines or other 
> runtimes built on top of C, I believe it will require some assistance from the C
> runtime to properly manage the shadow stack.

I think if we want to add an interface that's purely for configuring the
stack size to use that should be separate to clone3() since that's also
an issue for things using plain clone(), including workloads that can't
switch to clone3() due to it not playing nicely with seccomp.

I also previously suggested that if we want to enable reuse of stacks
after a thread has exited we should support having the kernel write a
token to the current pointer of exiting threads (mirroring how the stack
pivot instructions work), I didn't get any feedback on that suggestion.
I would expect this to be gated behind a separate ABI (most likely a new
permission on PR_SHADOW_STACK_SET_STATUS) so readily discoverable if
added independently.

> So, imho, the current clone3 interface for shadow stack token only adds an extra burden 
> to the C runtime, and since it is not yet in master, perhaps we can still refine it.

I have to say it is a little surprising to have this come up almost two
years into the review.
-------------- 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/20250917/560248f4/attachment.sig>