On Thu, Feb 3, 2022, at 5:08 PM, Edgecombe, Rick P wrote:

Hi Thomas,

quoted

quoted

       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?

quoted

quoted

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.