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

Yury Khrustalev yury.khrustalev@arm.com
Fri Sep 19 10:52:38 GMT 2025


On Fri, Sep 19, 2025 at 11:35:07AM +0100, Catalin Marinas 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:
> > > 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.
> ...
>
> 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 agree, if we defer kernel patches, nobody would be able to try setting
shadow stack size and thus there would be no uses, and we're back to
square one.

> I do expect at some
> point in the future to be asked to support this, maybe together with a
> pthread_attr_setshadowstack() extension.

This was exactly my thinking about the next step. This glibc patch series
allows for use of a custom size for the shadow stack but it still uses the
default size. With something like pthread_attr_setshadowstacksize() we'd
be able to allows applications to change shadow stack size per thread.

The default shadow stack size that is used currently may become
prohibitive for some applications due to performance limitations and
they might have to opt for not using shadow stacks at all which would be
unfortunate.

Yury



More information about the Libc-alpha mailing list