[PATCH v4 2/5] nptl: Add libc allocated shadow stack for new threads

[Mark Brown]

On Wed, Nov 26, 2025 at 11:10:50AM -0300, Adhemerval Zanella Netto wrote:
> On 26/11/25 11:03, Yury Khrustalev wrote:

> > Sorry, I don't think I understand what you mean. Could you please
> > clarify? GCS may be enabled for the main thread (which means for all
> > threads) at startup based on Glibc tunable. We could also prohibit
> > disabling GCS, but I don't see how this is relevant to allowing to
> > manage the size of shadow stack?

> I mean that once the thread start with GCS enabled with an user-defined
> stack, the newly created thread can disable GCS but it will still pay the
> price of the kernel-allocated shadow stack even if it explicit set the
> shadow stack size to 0 with pthread_attr_setshadowstacksize.

> It also means that pthread_attr_setshadowstacksize will *always* create a
> shadow stack even if the size is 0; which is at least confusing.

Yeah, that's a mildly annoying but falls out of the legacy clone()
support and general compatibility with the current userspace ABI.  We
could specify an interface that allows userspace to explicitly request
that a new thread be started with shadow stack disabled though I'm not
sure what the practical use case is there (I can see it from the point
of view of making the pthread API neat, you're right about the weird
edges) so I don't know how keen people would be to carry the code.

I don't think it's worth having an interface allowing shadow stack to be
enabled without one actually being allocated, such a thread just isn't
going to run usefully.
-------------- 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/20251126/4d2e51b4/attachment.sig>