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

[H.J. Lu]

On Mon, Sep 8, 2025 at 4:18 AM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 05/09/25 14:55, Mark Brown wrote:
> > On Fri, Sep 05, 2025 at 02:22:46PM -0300, Adhemerval Zanella Netto wrote:
> >
> >> So what is the advantage of extending clone3 to accept a map_shadow_stack
> >> stack if the idea is to not allow user re-use the allocated shadow guard
> >> region and forcing it to always deallocate it after thread finishes?
> >
> > It is possible to switch between shadow stacks at runtime with no kernel
> > intervention, if a userspace is doing that then there is no guarantee
> > that the shadow stack in use at the time the thread exits is the same
> > one that the thread was started with.  Potentially a thread will be
> > started with a stack that was previously in use in another context.  You
> > either end up with userspace having to deallocate stacks when they're
> > finished with or having the kernel always allocate a stack and userspace
> > pivot off that if it wants something else.
>
> 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.
>

Can glibc add a function, like releasecontext or freecontext, free any resources
associated with a context?


-- 
H.J.