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

[enh]

(sorry for the sort-of hijack, but i haven't seen a better place to
mention this...)

is there a plan for sigaltstack() yet? as android's libc maintainer
i'm particularly worried about that because android uses sigaltstack()
by default for everyone, so any "ignore this special case" plan would
be problematic for us.

(whereas android's libc doesn't reuse thread stacks, so that's not a
concern for us.)

On Fri, Sep 19, 2025 at 8:46 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Sep 18, 2025 at 03:33:57PM -0700, H.J. Lu wrote:
> > On Thu, Sep 18, 2025 at 3:23 PM Mark Brown <broonie@kernel.org> wrote:
>
> > > It is currently based on RLIMIT_STACK.
>
> > Can you point me to the kernel code where shadow stack size is determined?
>
> x86 code is here:
>
>    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/kernel/shstk.c#n225
>
> (it's the also using the normal stack size as well as RLIMIT_STACK).
>
> > > > 2.  Can it be solved differently with a prctl call?
>
> > > Yes, that has been suggested (including earlier in this thread) to try
> > > to help users who are restricted to regular clone() - either configuring
> > > the ratio or an absolute number.  There's been limited enthusiasm for it
> > > as the only option due to clunkiness if userspace wants different values
> > > for different threads (though that would be the common case of course).
>
> > The shadow stack configure option will be active until the next prctl call.
> > In the meantime, clone will use the same shadow stack configure option.
> > Different threads can have different shadow stack sizes.
>
> Right, it wasn't a "this doesn't work" but rather a "this is clunky,
> obviously we should be able to do this as part of clone3() instead"
> thing when it's come up previously.