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

[H.J. Lu]

On Tue, Dec 12, 2023 at 10:03 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 12/11/2023 08:44, H.J. Lu wrote:
> > On Mon, Dec 11, 2023 at 3:34 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > > The 12/06/2023 09:20, H.J. Lu wrote:
> > > > Sync with Linux kernel 6.6 shadow stack interface.  Since only x86-64 is
> > > > supported, i386 shadow stack codes are unchanged and CET shouldn't be
> > > > enabled for i386.
> > > >
> > > > 1. When the shadow stack base in TCB is unset, the default shadow stack
> > > > is in use.  Use the current shadow stack pointer as the marker for the
> > > > default shadow stack.
> > >
> > > what is the role of ssp_base in the tcb?
> >
> > It is used to identify if the current stack is the same as the target
> > shadow stack when switching ucontexts.  If yes, INCSSP will
> > be used to unwind shadow stack.  Otherwise, shadow stack
> > restore token will be used.
>
> i would like to support stack switching in longjmp too
> (for aarch64 gcs) not just in setcontext/swapcontext.
>
> if you assume that the target shadow stack always ends in a
> restore token when a jump is switching stack, then scanning
> the shadow stack until the token or current ssp is found works.
> (tcb ssp_base is not needed.)

We can't put a restore token on shadow stack for setjmp since
longjmp is optional, not required.  If longjmp isn't called, there
will be an extra restore token on shadow stack.  One way to
switch arbitrary shadow stack is to allow write shadow stack,
which will reduce security.

> the linear scanning affects longjmp performance but it seems
> the overhead is amortized by the creation of the stack frames.
>
> if you don't want this in longjmp, then code using it for task
> scheduling across worker threads have to be patched to use
> *context (means signal mask saving syscall overhead so some
> projects may not like this) or marked as non-shadow-stack compat.
>


-- 
H.J.