On Thu, 2018-08-30 at 19:59 +0200, Jann Horn wrote:

On Thu, Aug 30, 2018 at 7:58 PM Yu-cheng Yu [off-list ref]
wrote:

quoted

On Thu, 2018-08-30 at 10:33 -0700, Dave Hansen wrote:

quoted

On 08/30/2018 10:26 AM, Yu-cheng Yu wrote:

quoted

We don't have the guard page now, but there is a shadow stack
token
there, which cannot be used as a return address.

The overall concern is that we could overflow into a page that
we
did
not intend.  Either another actual shadow stack or something
that a
page
that the attacker constructed, like the transient scenario Jann
described.

A task could go beyond the bottom of its shadow stack by doing
either
'ret' or 'incssp'.  If it is the 'ret' case, the token prevents
it.
 If it is the 'incssp' case, a guard page cannot prevent it
entirely,
right?

I mean the other direction, on "call".

In the flow you described, if C writes to the overflow page before B
gets in with a 'call', the return address is still correct for B.  To
make an attack, C needs to write again before the TLB flush.  I agree
that is possible.

Assume we have a guard page, can someone in the short window do
recursive calls in B, move ssp to the end of the guard page, and
trigger the same again?  He can simply take the incssp route.