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

[Mark Brown]

On Fri, Sep 19, 2025 at 11:35:07AM +0100, Catalin Marinas wrote:

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

If there is a benefit being found from the thread stack cache (I guess
there must given that the code is there?) then I'd expect some of that
benefit would be found with the shadow stack.  There'd not be the
syscall overhead but you'd still save the cost of mapping and unmapping
memory, plus the CoW costs for the stacks.  How much that's worth
writing home about I don't know.

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

I suspect a bunch of the workloads that care about placemement aren't
public code, things like NUMA node allocation like you mention above I'd
expect to be in proprietary, often in house, software.

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

I tend to agree with Yury about the difficulties with the deployment
story here, the audience for this stuff is likely to want things to come
from their distros.
-------------- 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/20250919/35ae5300/attachment.sig>