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

[Adhemerval Zanella Netto]

On 26/11/25 11:03, Yury Khrustalev wrote:
> On Wed, Nov 26, 2025 at 10:58:08AM -0300, Adhemerval Zanella Netto wrote:
>>
>> On 26/11/25 10:41, Yury Khrustalev wrote:
>>> On Wed, Nov 26, 2025 at 10:28:29AM -0300, Adhemerval Zanella Netto wrote:
>>>>
>>>> On 07/11/25 06:35, Yury Khrustalev wrote:
>>>>> Includes aarch64 GCS support code, does not include x86 shstk
>>>>> support (should be similar to the aarch64 case).
>>>>>
>>> ...
>>>
>>>> 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.
>>>
>>> Arguably, GCS (or any shadow stack implementation) is an orthogonal
>>> security feature so we should not disable it implicitly because of
>>> something else that a user / application does. What we do here is
>>> just increasing control over memory usage.
>>
>> But currently we do not enforce GCS with PR_LOCK_SHADOW_STACK_STATUS, so any
>> thread change disable it but without any control of the shadow stack memory
>> usage.
> 
> Sorry, I don't think I understand what you mean. Could you please
> clarify? GCS may be enabled for the main thread (which means for all
> threads) at startup based on Glibc tunable. We could also prohibit
> disabling GCS, but I don't see how this is relevant to allowing to
> manage the size of shadow stack?
> 

I mean that once the thread start with GCS enabled with an user-defined
stack, the newly created thread can disable GCS but it will still pay the
price of the kernel-allocated shadow stack even if it explicit set the
shadow stack size to 0 with pthread_attr_setshadowstacksize.

It also means that pthread_attr_setshadowstacksize will *always* create a
shadow stack even if the size is 0; which is at least confusing.