Re: Shadow stack backtrace command name

[Florian Weimer via Gdb <gdb@sourceware.org>]

* Christina Schimpe:

> We are currently working on the implementation of the shadow stack backtrace.
> This is how we would print a shadow stack backtrace for signals:
>
> ~~~
> (gdb) bt shadow
> #0  0x00007ffff7c54d90 in __restore_rt from /lib64/libc.so.6
> #1  0x80007ffff79fffd8
> #2  0x00007ffff7c54ce6 in __GI_raise at ../sysdeps/posix/raise.c:27
> #3  0x000000000040115d in main at /tmp/amd64-shadow-stack-signal.c:32
> [...]
> ~~~

> This would be the corresponding ordinary stack:
> ~~~
> (gdb) bt
> #0  handler (signo=10) at /tmp/amd64-shadow-stack-signal.c:25
> #1  <signal handler called>
> #2  __pthread_kill_implementation ([...]) at pthread_kill.c:44
> #3  0x00007ffff7ca15f3 in __pthread_kill_internal (signo=10, threadid=<optimized out>) at pthread_kill.c:78
> #4  0x00007ffff7c54ce6 in __GI_raise (sig=10) at ../sysdeps/posix/raise.c:26
> #5  0x000000000040115d in main () at /tmp/amd64-shadow-stack-signal.c:31
> ~~~
> Do you see much value in combining the outputs?

The difference is that the shadow stack backtrace does not contain the
interrupted instruction, so frame #2 in the traditional backtrace.  This
is more important for CPU-generated signals such as division by zero or
invalid memory access, where you really want to see the fault address in
the backtrace.

> The elements on the shadow stack are following the description of the linux 
> kernel for signals:
> "When a signal happens, the old pre-signal state is pushed on the stack.
>  When shadow stack is enabled, the shadow stack specific state is pushed 
> onto the shadow stack. Today this is only the old SSP (shadow stack pointer),
>  pushed in a special format with bit 63 set."
> (https://docs.kernel.org/arch/x86/shstk.html)
>
> Frame 1 contains the old SSP with bit 63 set.

I would like the kernel to push the address of the interrupted
instruction as well, potentially with additional flag markup.  Or maybe
it's so early that we don't need it.  The signal return path would have
pop it off the stack and not validate it because I think it's an
expected use case to redirect execution from a signal handler by
patching the signal context.  Alternatively, the kernel could push the
address of the signal context, which might be even more useful.  I think
it would be useful if the shadow stack contained all the data needed to
implement the glibc backtrace function, not because glibc is important,
but because it seems to be a good indicator what programmers expect from
a backtrace.

We also need to figure out how this interacts with LAM.  Does the CPU
push tagged addresses onto the shadow stack?  It could impact the type
of tagging the kernel can use for its own special addresses.

Thanks,
Florian