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

[H.J. Lu]

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

Can you point me to the kernel code where shadow stack size is determined?

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

The shadow stack configure option will be active until the next prctl call.
In the meantime, clone will use the same shadow stack configure option.
Different threads can have different shadow stack sizes.

-- 
H.J.