[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJt8pk_E6OW85krDibn82-=pLTKi-ueg0PjCKXscDRak8v=FoA@mail.gmail.com>
Date: Wed, 9 Sep 2026 17:49:16 +0200
From: Pavel Labath <labath@...gle.com>
To: Florian Weimer <fweimer@...hat.com>, libc-coord@...ts.openwall.com
Subject: Re: An async-signal-safe way to get thread’s stack
On Wed, 9 Sept 2026 at 11:41, Florian Weimer <fweimer@...hat.com> wrote:
> I think AT_EXECFN is optional on Linux.
>
> But surely it would be possible to record the original stack pointer at
> the first entry point (dynamic linker startup code or static startup
> code)?
Recording the stack pointer at _start is definitely possible, and
arguably more correct. I did not do that for two reasons:
- the top of the VMA is what RLIMIT_STACK is counted from. This lets
users compute how far the stack is allowed to grow, for example.
- I think it better matches pthread_getattr_np for the non-main
threads, where the returned "stack" region also includes the Thread
Control Block and the initial TLS area
I know this isn't the most elegant solution, and I'm sure it needs
additional tweaks (maybe check for additional auxv values), but I
think it can be made to work reasonably well.
That said, this approach was based on the idea of creating something
that fits in as well as it can within the existing stack reporting
framework. This is why I did not consider segmented stacks (although,
to be fair, I did not know those exist), alternate stacks or
coroutines. If we want to build something new that covers all these
use cases, restricting this to the "proper" stack area may make sense.
>
> Exposing that information should be relatively straightforward. With
> the process_vm_readv optimization, maybe that is already helpful?
This is an interesting idea. Using a syscall for each memory access
would be too slow, but using it once per page just might work. I'll
have to play around with this.
>
> A full API would have to cover the realities of segmented stacks and
> coroutines, which would be quite involved (but libcs need to track this
> for shadow stacks at one point).
>
I may have oversold the scope of this proposal. While a general API to
get (all?) stacks of a thread would definitely be useful, it would
definitely be involved. I was thinking of a much more reduced scope -
a way to get stack information that the (pthread) library already has.
Basically an async-safe replacement for
pthread_getattr_np+pthread_attr_getstack. I think you could define it
as "the stack that was *initially* allocated for the given thread".
And I'm mainly interested in the non-main threads, as one can get the
main stack if one tries hard enough, it's the potential thousands of
threads created throughout the application that are tricky.
How does that sound? Not ambitious enough?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
