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

[H.J. Lu]

On Wed, Dec 13, 2023 at 4:20 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> 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.

Here are 2 patches:

1. Add a test for longjmp from a user context.
2. Check the restore token in longjmp.

Do they make sense?

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



-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-x86-64-cet-Check-the-restore-token-in-longjmp.patch
Type: text/x-patch
Size: 2137 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20231213/38c53e68/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-a-test-for-longjmp-from-user-context.patch
Type: text/x-patch
Size: 3025 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20231213/38c53e68/attachment-0001.bin>