On Fri, Sep 26, 2025 at 07:17:16PM +0000, Edgecombe, Rick P wrote:
On Fri, 2025-09-26 at 17:03 +0100, Mark Brown wrote:
On Fri, Sep 26, 2025 at 03:39:46PM +0000, Edgecombe, Rick P wrote:
What do you mean by "a fuller solution from the glibc side"? A solution for re-using shadow stacks?
I mean some code or a fuller explained solution that uses this new kernel functionality. I think the scheme that Florian suggested in the thread linked above (longjmp() to the start of the stack) will have trouble if the thread pivots to a new shadow stack before exiting (e.g. ucontext).
Is that supported even without user managed stacks?
IIUC longjmp() is sometimes used to implement user level thread switching. So for non-shadow stack my understanding is that longjmp() between user level threads is supported.
Yes, that was more a "does it actually work?" query than a "might someone reasonably want to do this?".
For shadow stack, I think user level threads are intended to be supported. So I don't see why a thread could never exit from another shadow stack? Is that what you are asking? Maybe we need to discuss this with the glibc folks.
There's a selection of them directly on this thread, and libc-alpha on CC, so hopefully they'll chime in. Unless I'm getting confused the code does appear to be doing an unwind, there's a lot of layers there so I might've got turned around though.
Again, I'm just thinking that we should vet the solution a bit more before actually adding this to the kernel. If the combined shadow stack effort eventually throws its hands up in frustration and goes with WRSS/GCSSTR for apps that want to do more advanced threading patterns, then we are already done on the kernel side.
Some more input from the glibc side would indeed be useful, I've not seen any thoughts on either this series or just turning on writability both of which are kind of orthogonal to clone3() (which has been dropped from -next today).