Messages in this thread | | | Date | Thu, 03 Feb 2022 21:20:05 -0800 | From | "Andy Lutomirski" <> | Subject | Re: [PATCH 00/35] Shadow stacks for userspace |
| |
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.
| |