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

[H.J. Lu]

On Thu, Sep 18, 2025 at 1:10 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Sep 18, 2025 at 06:30:08PM +0100, Catalin Marinas wrote:
> > On Thu, Sep 18, 2025 at 06:27:15PM +0100, Catalin Marinas wrote:
> > > > On Wed, Sep 17, 2025 at 04:29:36PM -0300, Adhemerval Zanella Netto wrote:
> > [... lots of text trimmed ...]
>
> > > > There is no requirement to use this interface at all, if userspace
> > > > doesn't use this interface it will continue to see the existing
> > > > behaviour.
>
> > I'd like to have at least a user of such interface, otherwise we just
> > maintain a user-kernel ABI that never gets exercised, other than
> > kselftests.
>
> Yes, clearly we want to end up with something that can be actually used.
>
> > Given that the kernel patches are possibly going into 6.18, we need some
> > quick decision on:
>
> > 1. Defer the kernel patches to 6.19 (or later) until the glibc
> >    discussion settles
>
> Ideally we'll be able to come to a conclusion fairly rapidly and not
> have to defer.
>
> > 2. Keep the clone3() interface as is and separately add a patch to
> >    re-instate the token on the shadow stack to facilitate reuse
>
> > 3. Another mechanism that allows shadow stack reuse independent of the
> >    clone3() interface
>
> I think a shadow stack reuse is a reasonable request, especially if we
> make it optional so that non-glibc userspaces can avoid it it it's not
> desired (though I'm not sure how big a concern that is so perhaps it's
> more trouble than it's worth).
>
> My specific suggestion here was to model this like stack pivoting (as we
> do for starting a thread in this series) so that when a thread exits we
> write a pivot token to the current pointer, allowing the stack to be
> used by another thread.  This would align with glibc's existing reuse of
> normal stacks, the initial feedback on the glibc patches was broadly
> "we're trying to have a thread stack cache here".  glibc already unwinds
> the userspace stack as part of a normal thread exit which would fit
> nicely with this approach.  If we want to make this optional then a flag
> on PR_SHADOW_STACK_STATUS seems sensible.
>
> AFAICT this is most closely aligned with what glibc is currently trying
> to do and it's straightforward enough to implement on the kernel side.
>
> > 4. Change the clone3() interface to allow a NULL shadow stack pointer
> >    but introduce a size to struct clone_args (it implies (1) above). The
> >    kernel would allocate the shadow stack accordingly
>
> To clarify we already allow a NULL shadow stack pointer (this gets you a
> kernel managed shadow stack as per the exitsting ABI), the change here
> would be to allow userspace to control the size of that kernel managed
> shadow stack.  I think this should be usable for userspace but does mean
> that it's not possible to do the cache of thread stacks, it was
> suggested as a "if we can't do reuse..." thing.
>
> My main concern with this approach is that it's only offering limited
> control to userspace so I think even if we don't now we will inevitably
> end up wanting to make userspace managed allocation work, the existing
> glibc thread stack cache is a current example and I can imagine a
> runtime wanting to do things like switching green threads to real
> threads.
>
> > 5. Any other option? This likely implies (1)
>
> I guess there's also option allowing configuration of stack size only
> (without the ability for userspace to manage the allocation).  That has
> the same limitations as configuring the stack size.
>
> I don't think I've seen any other suggestions.
>
> > The prctl() to set a default shadow stack size is a good discussion to
> > have but complementary to the clone3() interface.
>
> I agree, that idea is mainly directed at the userspaces that find they
> need to block clone3().
>
> > So, if Yury's nptl patches using clone3() aren't going in, I'd rather
> > opt for (1) w.r.t. the kernel patches. I know we had these patches
> > around for nearly two years but I also like to see some users of the
> > interface longer term.
>
> If we can agree that that the interface in the current series is a good
> one for thread creation it would be good to get it merged, so long as we
> have a clear plan for what needs to be added.  That would be helpful for
> both cleanup work on the shadow stack support (I've got a bit of a list
> there, largely pulling stuff out into common code but some general
> improvements too) and the RISC-V support (which is itself almost there,
> it'd be good if it could have clone3() from day one).  The less code we
> have in flight, and the simpler the decisions involved in the code that
> is in flight, the easier it will be to get the many different people who
> need to look at this stuff to do so.

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.


-- 
H.J.