Re: Shadow stack backtrace command name

Tom Tromey <[email protected]> writes:

>>>>>> Schimpe, Christina via Gdb <[email protected]> writes:
>
>> A shadow stack is a second stack for a program introduced in the Intel (R)
>> Control-Flow Enforcement Technology (CET).  The shadow stack is used for
>> control transfer operations to store the return addresses.
>
> One question I had is when, as a gdb user, would I want to see this
> information?

I think the most common shadow stack error a GDB user would encounter
would be when the inferior is returning from a function and gets a
SIGSEGV because the return address is wrong (e.g., because a buffer
overflow wrote over it).

There are other possibilities, for example a program can create
different shadow stacks and switch between them (e.g., when it
implements userspace-level threading) so some error could happen during
that process. E.g., in AArch64's Guarded Control Stacks, there needs to
be a special "cap" value at the end of the incoming stack and a SIGSEGV
is generated if that's not the case. In this case I think the user would
want to be able to direct the shadow stack backtrace command to print
the backtrace of that other stack, instead of the currently active one.

Another example would be trying to write to a mapped shadow stack that
is read-only. That also causes a SIGSEGV. Though not sure if the shadow
stack backtrace is relevant in this scenario.

>> It is configurable using "print symbol-filename" and COUNT.
>> The command can be called by the following names:
>> - "info shadow-stack bt", "info shadow-stack backtrace"
>
> Like others in the thread, I'm -1 on "info" as a prefix.
> I liked "bt -shadow", but I was also wondering if the information should
> just be integrated into the ordinary backtrace when available... that's
> why I'm wondering when I'd want to see this.

In my first example, it would be useful if the regular backtrace output
noted where it differs from the shadow stack. Though I think a way to
see the shadow stack backtrace by itself would still be useful.

-- 
Thiago