Re: [PATCH 11/17] x86/cet: Sync with Linux kernel 6.6 shadow stack interface

["H.J. Lu" <hjl.tools@gmail.com>]

On Wed, Dec 13, 2023 at 3:54 PM Edgecombe, Rick P
<rick.p.edgecombe@intel.com> wrote:
>
> On Wed, 2023-12-13 at 14:45 -0800, H.J. Lu wrote:
> > > longjmp cannot target arbitrary setjmp that happened on another
> > > stack: if that stack is still in use by another thread then the
> > > two threads clobber each other's stack. it can only work if that
> > > stack is switched away from and at that point a token was placed.
> > > we can make this the abi: you can only longjmp to a stack which
> > > is switched away from such that a token is placed on it.
> >
> > The restore token is put on shadow stack by setcontext and
> > swapcontext.   When longjmp is called, it doesn't know if there
> > is a token or not.  If longjmp keeps searching for the token and
> > doesn't find it, it will run out of shadow stack.  Rick, can we
> > assume that the shadow stack entries are 0, if they aren't in
> > use?
>
> Not sure what you mean by entries not in use. You mean the restore
> token? The shadow stack entries are not zeroed as they are popped by
> RET.
>

longjmp needs to know when to stop searching the token since there
won't be one if setcontext and swapcontext aren't called on the shadow
stack where setjmp is called.  Will checking for zero shadow stack entry
value work here?  It is OK if the value isn't zeroed by RET as long as
zero value can be checked to avoid going beyond the shadow stack boundary.

> longjmp() doesn't return an error code, so is a crash actually ok here?
>
>
> I'm remembering another issue that came up when this idea was discussed
> before. Apps might not call SAVEPREVSSP after they RSTORSSP. You can
> just just swap away and not leave a token. So setjmp() cannot be
> guaranteed to work with custom stack switching code. It has to be one
> of the rules, at least for x86.
>
> I need to go dig through the mails, but I thought there were some more
> limitations (that could also be rules) that we ran into.



-- 
H.J.