Re: [PATCH 00/35] Shadow stacks for userspace

Andy Lutomirski
2022-02-04T05:20:34Z

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.