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

[Adhemerval Zanella Netto]

On 08/09/25 16:08, H.J. Lu wrote:
> 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?

Yes, but it does not really help current code that does. And makecontext/swapcontext 
were removed from POSIX-2008; so adding a glibc extension for a deprecated POSIX 
feature does not seems a good way forward.