Re: [PATCH 7/9] gdb: Provide gdbarch hook to distinguish shadow stack backtrace elements.

[Thiago Jung Bauermann <thiago.bauermann@linaro.org>]

Hello,

"Schimpe, Christina" <christina.schimpe@intel.com> writes:

>> -----Original Message-----
>> From: Eli Zaretskii <eliz@gnu.org>
>> Sent: Tuesday, September 23, 2025 1:50 PM
>> To: Schimpe, Christina <christina.schimpe@intel.com>
>> Cc: gdb-patches@sourceware.org
>> Subject: Re: [PATCH 7/9] gdb: Provide gdbarch hook to distinguish shadow
>> stack backtrace elements.
>> 
>> > From: Christina Schimpe <christina.schimpe@intel.com>
>> > Date: Tue, 23 Sep 2025 11:18:40 +0000
>> >
>> > On x86 with CET there can be elements on the shadow stack which are
>> > not return addresses.  In this case, we just want to print the element
>> > itself in the shadow stack backtrace, but no further information.
>> >
>> > Provide a gdbarch hook to distinguish between return and non-return
>> > addresses and use it to print the shadow stack backtrace as described
>> > above.
>> > ---
>> >  gdb/doc/gdb.texinfo       | 19 ++++++++++++
>> >  gdb/gdbarch-gen.c         | 32 ++++++++++++++++++++
>> >  gdb/gdbarch-gen.h         | 15 +++++++++
>> >  gdb/gdbarch.h             |  1 +
>> >  gdb/gdbarch_components.py | 17 +++++++++++
>> >  gdb/shadow-stack.c        | 64 +++++++++++++++++----------------------
>> >  gdb/shadow-stack.h        | 37 ++++++++++++++++++++++
>> >  7 files changed, 148 insertions(+), 37 deletions(-)
>> 
>> Thanks.
>> 
>> > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index
>> > ebda4546b58..a0fde385a8e 100644
>> > --- a/gdb/doc/gdb.texinfo
>> > +++ b/gdb/doc/gdb.texinfo
>> > @@ -8887,6 +8887,25 @@ This is how a shadow stack backtrace looks like
>> on amd64:
>> >  @end group
>> >  @end smallexample
>> >
>> > +There can be elements on the shadow stack which are not return
>> > +addresses, for example on x86 with the Intel Control-Flow Enforcement
>> > +Technology (@xref{CET}).  In case of signals, the old shadow stack
>> > +pointer is pushed
>>                ^
>> A cross-reference is missing here.
>
> Thanks will fix.
>
>> > +in a special format with bit 63 set.  For such shadow stack elements,
>> > +the shadow stack frame just contains the level and the address on the
>> > +shadow stack, as shown in the following example by frame 1:
>> > +
>> > +@smallexample
>> > +@group
>> > +(gdb) bt shadow 4
>> > +#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
>> > +(More shadow stack frames follow...)
>> > +@end group
>> > +@end smallexample
>> 
>> Would it make sense to show something like "<signal caught>", instead of a
>> frame with only an address?
>
> Yeah, this is a good idea, I wondered about a similar thing actually but wanted to discuss
> the general direction for handling those specific elements on the shadow stack first.
> Maybe there are more options on other architectures that we have to consider.
> Let's wait for more feedback on this, I added Thiago again in cc here.

Yes, I would like to show a "<signal handler called>" message in the
corresponding shadow stack entry, as is done in the regular stack:

  (gdb) bt
  #0  handler (signo=10) at aarch64-gcs-signal.c:59
  #1  <signal handler called>
  #2  __pthread_kill_implementation (threadid=281474842447584, signo=signo@entry=10, no_tid=no_tid@entry=0)
      at ./nptl/pthread_kill.c:44
  #3  0x0000fffff7e77670 in __pthread_kill_internal (signo=10, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
  #4  0x0000fffff7e2cb3c in __GI_raise (sig=10) at ../sysdeps/posix/raise.c:26
  #5  0x0000aaaaaaaa0b24 in main () at aarch64-gcs-signal.c:96

Here is the corresponding GCS backtrace:

  (gdb) bt shadow
  #0  0x0000fffff7ffa85c in __kernel_rt_sigreturn
  #1  0x0000fffff7bff000 in ??
  #2  0x0000fffff7e2cb3c in __GI_raise at ../sysdeps/posix/raise.c:27
  #3  0x0000aaaaaaaa0b24 in main at aarch64-gcs-signal.c:99

In this example "<signal handler called>" message would replace the VDSO
function name in entry #0. Also note that it's an actual return address
but we still want to show a custom message for it.

Finally, notice that there's GCS entry #1, which isn't a return
address. It's a "cap record", which marks that the stack is currently
not in use. When a signal is delivered, the kernel pushes two entries to
the thread's GCS: first the cap record, then the address to the signal
trampoline (__kernel_rt_sigreturn). For this entry, I'd like to show
"<cap record>".

One suggestion to handle that is to make
do_print_shadow_stack_frame_info call a new hook
gdbarch_print_shadow_stack_frame_info which would allow the architecture
to print the shadow stack frame however it wants. If the hook returns
false, then do_print_shadow_stack_frame_info would print the information
itself, as it does in your patch. What do you think?

-- 
Thiago