lkml.org 
[lkml]   [2022]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2022-02-04 06:21    [W:0.217 / U:0.180 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site