On Thu, Feb 3, 2022, at 5:08 PM, Edgecombe, Rick P wrote: > Hi Thomas, >> > Signals >> > ------- >> > Originally signals placed the location of the shadow stack >> > restore >> > token inside the saved state on the stack. This was >> > problematic from a >> > past ABI promises perspective. What was the actual problem? >> > So the restore location was >> > instead just >> > assumed from the shadow stack pointer. This works because in >> > normal >> > allowed cases of calling sigreturn, the shadow stack pointer >> > should be >> > right at the restore token at that time. There is no >> > alternate shadow >> > stack support. If an alt shadow stack is added later we >> > would >> > need to >> >> So how is that going to work? altstack is not an esoteric corner >> case. > > My understanding is that the main usages for the signal stack were > handling stack overflows and corruption. Since the shadow stack only > contains return addresses rather than large stack allocations, and is > not generally writable or pivotable, I thought there was a good > possibility an alt shadow stack would not end up being especially > useful. Does it seem like reasonable guesswork? It's also used for things like DOSEMU that execute in a weird context and then trap back out to the outer program using a signal handler and an altstack. Also, imagine someone writing a SIGSEGV handler specifically intended to handle shadow stack overflow. The shadow stack can be pivoted using RSTORSSP.
