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

[Mark Brown]

On Wed, Sep 17, 2025 at 04:29:36PM -0300, Adhemerval Zanella Netto wrote:
> On 17/09/25 14:37, Mark Brown wrote:

> > 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.

> It is not clear to me how can you accomplish it without also tying the
> allocation to some handler the kernel would provide (which is what 
> map_shadow_stack does essentially).  

Remember that we have kernel allocated shadow stacks if one isn't
explictly provided, the size of which is a number we currently pull out
of thin air as far as userspace is concerned so we pick an extremely
high value.  We can add a prctl() or something to configure that number.

> > 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.

> Sorry if I missed it, if the kernel can provide it I think it would
> be useful.

OK, great.  I think that if we've got that then you'd not have any
concerns, you'd be able to reuse the stacks from threads that exit
cleanly?  For those that don't I imagine it'd be more trouble than it's
worth to work out where the token ended up so you'd be just as well
throwing the GCS away and starting over but that seems reasonable.

> >> 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.

> Perhaps because it was only recently discussed how it would be implemented in glibc?
> (I do not follow lkml that clone, but maybe I should more).

There's been glibc people on copy for the kernel thread the whole time,
I guess the wrong ones though, and I had thought that some earlier code
had been posted though it's possible I got the wrong end of the stick
there.

> Previously, when I reviewed the initial GCS work, I had the impression that the shadow 
> stack was supposed to be transparently managed by the kernel through the clone3 syscall 
> and that map_shadow_stack was added to manage the corner cases of setjmp calls and the 
> possible usage of green-threads.

That's the current case, yes.  All the clone() family of syscalls will
transparently give you a shadow stack if needed with the shadow stack
support that is in currently released kernels.  The existing ABI was
designed prior to clone3() existing at all.

> What I am trying to say is that with the current ABI, it only adds an extra burden on 
> userland to manage the shadow stacks for most runtimes. However, if the defined kernel 
> ABI is used, it can work out this on glibc. 

There is no requirement to use this interface at all, if userspace
doesn't use this interface it will continue to see the existing
behaviour.
-------------- 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/bf384a90/attachment.sig>