RE: Shadow stack backtrace command name

> * 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?  

No, I don't think so. For LAM only tagged data pointers are supported. 

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