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

[Catalin Marinas]

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

As Yury and Mark pointed out, currently the shadow stack size allocated
by the kernel is half the thread stack size (either the one passed via
clone3() or the default RLIMIT_STACK). It is fairly arbitrary, though
not sure glibc knows any better, I think it makes a similar guess as the
kernel.

>From the kernel perspective, allowing user-space control of both size
and location of the shadow stack makes sense. We do this for the normal
stack already via clone() and clone3(). The former did not allow more
arguments for the shadow stack, hence the clone3() extension here. If
glibc is fine with the default, kernel-managed shadow stack and size and
not implementing any optimisations like stack reuse (I don't think it
does this for the normal stack either), these changes don't really
improve anything.

What's missing though is allowing a user program (not the libc directly)
control over the shadow stack placement. Given that shadow stacks are
fairly new, we don't have an API like pthread_attr_setstack(). Its use
is not very common though, a quick search in Debian shows only DPDK
using it in a meaningful way (it wants specific NUMA node placement). I
expect some other programs making heavy use of threads to benefit from
more control over where the (shadow) stacks are placed.

We can defer merging the kernel patches until a concrete user turns up
but we'll have a bit of a chicken and egg situation. I do expect at some
point in the future to be asked to support this, maybe together with a
pthread_attr_setshadowstack() extension.

-- 
Catalin