The 03/06/2023 18:08, Edgecombe, Rick P wrote: > On Mon, 2023-03-06 at 17:31 +0100, Florian Weimer wrote: > > I assume there is no desire at all on the kernel side that > > sigaltstack > > transparently allocates the shadow stack? > > It could have some nice benefit for some apps, so I did look into it. > > > Because there is no > > deallocation function today for sigaltstack? > > Yea, this is why we can't do it transparently. There was some > discussion up the thread on this. changing/disabling the alt stack is not valid while a handler is executing on it. if we don't allow jumping out and back to an alt stack (swapcontext) then there can be only one alt stack live per thread and change/disable can do the shadow stack free. if jump back is allowed (linux even makes it race-free with SS_AUTODISARM) then the life-time of alt stack is extended beyond change/disable (jump back to an unregistered alt stack). to support jump back to an alt stack the requirements are 1) user has to manage an alt shadow stack together with the alt stack (requies user code change, not just libc). 2) kernel has to push a restore token on the thread shadow stack on signal entry (at least in case of alt shadow stack, and deal with corner cases around shadow stack overflow).
