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

[enh]

On Wed, Oct 1, 2025 at 3:38 PM Edgecombe, Rick P
<rick.p.edgecombe@intel.com> wrote:
>
> On Wed, 2025-10-01 at 18:34 +0100, Mark Brown wrote:
> > On Wed, Oct 01, 2025 at 12:24:32PM -0400, enh wrote:
> >
> > > 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.)
> >
> > I've not heard of one - we've talked around it a bunch but the
> > conclusion of the last discussion I remember was basically that nobody
> > involved at the time had a concrete use case for them so we felt we were
> > just talking endlessly around things without a clear idea of the
> > tradeoffs we might be making.  IIRC the concerns were about how to
> > represent switching to the alternate stack, especially when the switch
> > was due to the main stack being exhausted.
>
> I had a POC in this revision:
> https://lore.kernel.org/lkml/20220929222936.14584-1-rick.p.edgecombe@intel.com/
>
> Since sigaltstack() doesn't have an alloc/free pattern in the API there isn't a
> way to do it automatically for existing apps. It sounds like that is not a
> problem for this usage?

bionic basically mmap()s two stacks for every thread, and calls
sigaltstack() for you. (so as long as there's some way for us to
explain to the kernel what's going on, that's fine --- we can just
change pthread_create() [and main thread initialization] to do that.)

> But, yea, as Mark says it wades into the territory of which stack jumping
> operations are supposed to work with each, and whether we should just start to
> use the write shadow stack primitives to address it.
>
> Actually, for Android's usage is there an opinion on whether you would rather
> have a more locked down implementation, or one that is more flexible regarding
> stack switching? (i.e. longjmp()ing off of alt stacks, etc)

i'd assume from previous interactions with our security folks that the
default preference would be safety > flexibility. (we don't have
_tests_ for longjmp() off alt stacks, but of course that doesn't mean
there aren't apps doing it. but then, they'd have to fix that
themselves if/when they switch to shadow stacks, so that seems fine?)