Re: Shadow stack backtrace command name

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

* Christina Schimpe:

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

> You can run "info proc status" and check for "shstk" in
> x86_Thread_features, see https://docs.kernel.org/arch/x86/shstk.html.

Thanks, that's a bit better than this (for SHSTK enabled):

(gdb) print (*(tcbhead_t *)$fs_base)->feature_1
$1 = 2

Florian