[PATCH v4 2/5] nptl: Add libc allocated shadow stack for new threads

[Mark Brown]

On Wed, Nov 26, 2025 at 10:28:29AM -0300, Adhemerval Zanella Netto wrote:
> On 07/11/25 06:35, Yury Khrustalev wrote:

> What happens if we do not allocate a shadow stack and pass NULL for 'shadow_stack_token'?
> Will kernel not enable shadow stack for PR_SHADOW_STACK_ENABLE or will clone3 fail?

That will give you the current behaviour - if shadow stack is enabled
for the caller the kernel will allocate one for the newly created thread.

> I wonder if we should stop allocating a shadow stack for user-defined stacks, similar on
> how we handle guard pages.  My understanding in such situations, users aims to control
> exactly the memory usage of threads and GCS adds an extra burden for each thread.

The clone3() patch doesn't give you a way to start a thread with shadow
stacks enabled but not allocated, either you allocate one yourself or
the kernel will do it for you.  Given that you can't do function calls
in such a context it's not a particularly useful one.
-------------- 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/20251126/bd101576/attachment.sig>