Re: [PATCH v2 0/9] Add new command to print the shadow stack backtrace

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

Hello Christina,

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

>> -----Original Message-----
>> From: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
>> Sent: Donnerstag, 7. Mai 2026 06:14
>> To: Schimpe, Christina <christina.schimpe@intel.com>
>> Cc: gdb-patches@sourceware.org
>> Subject: Re: [PATCH v2 0/9] Add new command to print the shadow stack
>> backtrace
>> 
>> > 3) For non-return addresses on the shadow stack, we want to display a
>> > string, as already implemented for signals.  For inferior calls, we
>> > also want to display <function called by GDB>.  The return address for
>> > inferior calls is pushed onto the shadow stack by GDB, but we
>> > currently don’t have a way to distinguish this address from normal
>> > return addresses.  Thiago suggested pushing the return address
>> > together with a marker, but it’s still unclear how this marker should look
>> like.
>> 
>> In AArch64 GCS, we can have "cap" entries which are markers in the stack.
>> Bits 63-12 of the entry have to be the address of the cap entry itself, but bits
>> 11-0 can be arbitrary values. I think the equivalent in
>> x86 shadow stacks would be an entry with the 63 bit set. Can the other bits
>> have an arbitrary value?
>> 
>> If so, before we push the return address for the inferior call, we could push a
>> cap entry / data entry with a magic value reserved for GDB to mark dummy
>> shadow stack frames. Then GDB would know that the next entry after it
>> would be the return address for the inferior call.
>> 
>> Then when printing a shadow stack frame, we can check whether the entry
>> immediately preceding it has the magic value and print "<function called b
>> GDB>".
>
> In a different email I gave an update about this:
> https://sourceware.org/pipermail/gdb-patches/2026-March/225486.html
> This works without pushing anything on the shadow stack, so I'd prefer that solution.
> Would you be ok with that?

Yes, I agree it's a better solution. Glad you found it.

>> The parts from your latest reply:
>> 
>> ----
>> >> 3. We can change GDB to also put a marker in the shadow stack when it
>> >> does an inferior function call, and look for it in the shadow stack.
>> >
>> > We call shadow_stack_push in generic GDB code. Do you think we could
>> > find an architecture independent marker ?
>> > Then we can also return true with the gdbarch hook
>> > is_no_return_address and set the  string to <function called from gdb>.
>> 
>> I don't think we can find an arch independent marker. In x86, I believe the
>> marker would have to have bit 63 set. While in AArch64 bits 63-12 of the
>> entry need to have the same value as the address of the entry itself. Only bits
>> 11-0 of the entry are free to have an arbitrary token value.
>> 
>> > I am just not sure if the linux kernel ever decides to extend its
>> > functionality for CET shadow stack and uses the bits that we use for our
>> marker.
>> > In theory the linux kernel could decide to support 32bit shadow stack
>> > for x86 one day, or supervisor shadow stacks – and I am not sure what
>> > bits the kernel might set in the shadow stack elements to support this.
>> > I wonder if we should discuss this in the linux kernel mailing lists.
>> 
>> Good idea, it makes sense to coordinate with the kernel people to see if we
>> can/should reserve a magic token/data value to use in GDB for dummy
>> shadow stack frames. I'll ask the arm64 kernel people to see if they have an
>> opinion on the topic.
>
> With my proposed solution this is no longer necessary. 

Nice!

>> > 4) For signals, we also want to print <signal handler called>, as in
>> > the normal backtrace.  Since in this case we have a normal return
>> > address on the shadow stack, it’s not yet clear to me how to implement
>> this.
>> 
>> On AArch64, when calling a signal handler the kernel pushes a signal cap
>> entry where bits 11-0 have the value 0. So to recognize the shadow stack
>> entry which should be labelled "<signal handler called>", we just need to look
>> at the older entry and see if it's the signal cap entry.
>
> That one I solved now differently, too. 
> With a bit refactoring I can reuse the "amd64_linux_sigtramp_p" function.
> Do you have sth. similar for ARM?

No but an AArch64 version can be created that would look for the signal
cap that I mentioned, or alternatively (if I'm not mistaken) read the
actual trampoline instructions in the inferior to recognize it.

-- 
Thiago
(he/him)