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

[Mark Brown]

On Thu, Sep 18, 2025 at 01:24:32PM -0700, H.J. Lu wrote:
> On Thu, Sep 18, 2025, 1:21 PM Mark Brown <broonie@kernel.org> wrote:
> > On Thu, Sep 18, 2025 at 01:16:57PM -0700, H.J. Lu wrote:

> > > Given that clone3 isn't required for shadow stack support in glibc,
> > > we should delay the clone3 decision until we have a solid use case to
> > > require clone3 for shadow stack in glibc.

> > Do you see the thread stack cache as a solid use case?

> Does glibc work without the clone3 change?

glibc has existing support for shadow stacks which works fine but has
the shadow stacks managed by the kernel.  This works for most use cases
but allocates and frees the shadow stacks with threads and offers no
control over the size of the allocated shadow stacks so uses a very
conservative (ie, large) size.  The clone3() support would enable
control over the size and, if we do something about reuse of shadow
stacks from exited threads, caching of shadow stacks.

The control over size helps memory constrained systems or processes
avoid running into limits, especially if they use many threads or the
system has disable overcommit.  The thread stack cache is AIUI intended
as a performance improvement.
-------------- 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/20250918/ab201693/attachment.sig>