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

[Mark Brown]

On Mon, Sep 08, 2025 at 08:18:07AM -0300, Adhemerval Zanella Netto wrote:

> But this is not the usual programming mode for pthread code, and in places
> glibc does it (makecontext) it leaks the allocate shadow stack anyway.  I
> can't not say much what other runtime might do wrt shadow stack management,
> or if users will mess with stack pointer along with pthread; but in either
> cases it seems that the shadow stack management is out of scope of the C
> runtime.

> So maybe if clone3 just allows to setup the expected shadow stack size instead
> of requiring C runtime to manage the shadow stack itself would be a 
> more straightforward interface to use along pthread.

Right, the cases that might be switching the shadow stacks around aren't
vanilla pthread ones, those are very straightforward.

> >> Wouldn't it be simpler to extend clone3 with a preferred guard size instead,
> >> an let the kernel allocate/deallocate the shadow guard region instead?

> > I'm not sure what you mean when you're talking about "guard" here, are
> > you just taking about the shadow stack there or some additional guard
> > region around it?

> Sorry, I meant the shadow stack (I though using the terms
> Documentation/arch/arm64/gcs.rst uses would be more clear).

The guarded control stack consists of pages which (for userspace) have
the UnprivGCS permission, you might refer to such pages as guarded pages
but that's not a term in the architecture.  The architecture explicitly
mentions guard pages with the standard meaning as a separate concept to
the GCS (eg, I_QLKKL).
-------------- 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/20250908/3f838550/attachment.sig>