On Sat, Feb 5, 2022 at 5:27 AM David Laight [off-list ref] wrote:

From: Edgecombe, Rick P

quoted

Sent: 04 February 2022 01:08
Hi Thomas,

Thanks for feedback on the plan.

On Thu, 2022-02-03 at 22:07 +0100, Thomas Gleixner wrote:

quoted

quoted

Until now, the enabling effort was trying to support both Shadow
Stack and IBT.
This history will focus on a few areas of the shadow stack
development history
that I thought stood out.

       Signals
       -------
       Originally signals placed the location of the shadow stack
restore
       token inside the saved state on the stack. This was
problematic from a
       past ABI promises perspective. So the restore location was
instead just
       assumed from the shadow stack pointer. This works because in
normal
       allowed cases of calling sigreturn, the shadow stack pointer
should be
       right at the restore token at that time. There is no
alternate shadow
       stack support. If an alt shadow stack is added later we
would
       need to

So how is that going to work? altstack is not an esoteric corner
case.

My understanding is that the main usages for the signal stack were
handling stack overflows and corruption. Since the shadow stack only
contains return addresses rather than large stack allocations, and is
not generally writable or pivotable, I thought there was a good
possibility an alt shadow stack would not end up being especially
useful. Does it seem like reasonable guesswork?

The other 'problem' is that it is valid to longjump out of a signal handler.
These days you have to use siglongjmp() not longjmp() but it is still used.

It is probably also valid to use siglongjmp() to jump from a nested
signal handler into the outer handler.
Given both signal handlers can have their own stack, there can be three
stacks involved.

I think the shadow stack pointer has to be in ucontext - which also
means the application can change it before returning from a signal.
In much the same way as all the segment registers can be changed
leading to all the nasty bugs when the final 'return to user' code
traps in kernel when loading invalid segment registers or executing iret.

Hmmm... do shadow stacks mean that longjmp() has to be a system call?

No.  setjmp/longjmp save and restore shadow stack pointer.

--
H.J.