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

[Edgecombe, Rick P]

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() 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.