RE: Shadow stack backtrace command name

["Schimpe, Christina via Gdb" <gdb@sourceware.org>]

> >> * Christina via Gdb Schimpe:
> >>
> >> > However, based on the use cases that I am aware of, I am not sure
> >> > if the user wants to always see the shadow stack bt in the ordinary
> >> > bt output (if shadow stack is enabled).
> >>
> >> Based on my experiments, Linux currently does not push the
> >> instruction pointer onto the shadow stack if code is interrupted by a
> >> signal.  It still works because the return mechanism is different.
> >> This would be a very visible difference between ordinary backtraces and
> shadow stack based backtraces.
> >> As far as I understand it, the kernel could change, and it may still
> >> be early enough to make this change.
> >
> > Could you explain a bit why and what you think the kernel will change ?
> 
> I could imagine that an additional address is pushed onto the shadow stack
> when a signal is delivered, so that we can get a full backtrace across signal
> returns.
> 
> > Just to be sure that I understand correctly:
> 
> > Do you think that this different display for the ordinary and shadow
> > stack bt in case of signals is one argument more for displaying the
> > stacks together?  How would this look like?
> 
> Currently, it's not possible to use shadow stacks for backtraces because you
> won't be able to print the location after <signal handler called> line.  At least
> that's what I encountered when I tried to use shadow stack for implementing
> the glibc backtrace function.

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
[...]
~~~

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.

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? 

Christina
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Sean Fennelly, Jeffrey Schneiderman, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928