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

[Yury Khrustalev]

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?