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

[H.J. Lu]

On Thu, Sep 18, 2025 at 1:55 PM Mark Brown <broonie@kernel.org> wrote:
>
> 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

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 have 2 questions:

1. Can kernel improve shadow stack size calculation based on the stack
size?
2.  Can it be solved differently with a prctl call?

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



-- 
H.J.