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

[Mark Brown]

On Thu, Sep 18, 2025 at 02:56:23PM -0700, H.J. Lu wrote:
> On Thu, Sep 18, 2025 at 1:55 PM Mark Brown <broonie@kernel.org> wrote:

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

> So, the main issue is the very conservative/large shadow stack size.
> Can you open a glibc bug with a run-time testcase to show the issue?

I'll try to look into that tomorrow.

> I have 2 questions:

> 1. Can kernel improve shadow stack size calculation based on the stack
> size?

It is currently based on RLIMIT_STACK.

> 2.  Can it be solved differently with a prctl call?

Yes, that has been suggested (including earlier in this thread) to try
to help users who are restricted to regular clone() - either configuring
the ratio or an absolute number.  There's been limited enthusiasm for it
as the only option due to clunkiness if userspace wants different values
for different threads (though that would be the common case of course).
-------------- 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/610103d8/attachment-0001.sig>