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

["Schimpe, Christina" <christina.schimpe@intel.com>]

Hi Thiago, 

Please find my comments below.

> -----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
> 
> 
> Hello Christina,
> 
> I had a look at the review threads for v1 and v2 of this patch series, and I
> think the discussion below cover the loose ends that were still unaddressed.
> Please let me know if I am missing anything, or if there anything else you
> want to bring up before posting v3.
> 
> Christina Schimpe <christina.schimpe@intel.com> writes:
> 
> > Opens:
> 
> Hoisting up the lines below from your email because in this reply I need to
> reference them first:
> 
> > My latest reply regarding items 1-4 can be found here:
> > https://sourceware.org/pipermail/gdb-patches/2026-January/224054.html
> 
> I never replied to that email (sorry), so I'll paste below between "----" markers
> the parts corresponding to the open items, and finally reply to them here.
> Hopefully it's less confusing than resurrecting that thread.
> 
> > 1) Thiago suggested changing the frame numbering so that it always
> > starts at #1, since for the shadow stack we don't have frame #0
> > printed by the normal backtrace.
> > 2) Or, consider printing frame arguments and frame #0 similarly to
> > what the normal backtrace does.
> 
> Here are the parts about 1 and 2:
> 
> ----
> > Thinking about this again I wonder if it's a good idea to start the
> > numbering with #1.  Besides frame #0, there are multiple reasons why
> > the numbering of the normal backtrace is out-of-sync with the shadow
> > stack backtrace, e.g. inline calls, tail calls or python frame
> > filters.
> 
> Indeed this is true. There are many cases where the numbers will be out of
> sync (I hadn't considered Python frame filters!). I still think it's less confusing
> if the shadow stack starts numbering at 1. But that is because I think it makes
> sense to try to keep the regular stack backtrace and the shadow stack
> backtrace similar when it's not too hard to do so.
> 
> However: my understanding is that your inclination is to make the shadow
> backtrace faithfully present the actual contents of the shadow stack as they
> are in shadow stack memory. That makes a lot of sense too, and I can agree
> with that.
> 
> So to be honest I have a preference to start numbering the shadow stack
> frames at 1, but it's not a strong one. If you prefer to start numbering at 0,
> that is fine by me.

I don't have a strong opinion, too. In any case, I can always change that easily.  
Maybe someone else will comment on this, too.  Let's wait a little. 

> > Another option is to add the original #0 frame using the current $pc.
> > But what I don’t like about this, is that the user could be confused
> > and think that $pc is on the shadow stack.
> 
> I agree that it is confusing. I prefer not to show the current $pc in the shadow
> stack backtrace.
> ----
> 
> In that email you also said (in the part where we were talking about line
> numbers displayed for the return address):
> 
> > ...but since the overall direction is to align more with the normal
> > backtrace, I agree with you here. 😊
> 
> I'd like to comment that it's the "overall direction" in the sense that it's the
> direction my comments point to, but it's just my opinion.  I think it also
> makes sense to make "bt -shadow" more closely reflect the actual contents of
> the shadow stack.
> 
> So if regarding the alternatives we are considering for the output of "bt -
> shadow" (stack frame numbering, printing or not of function arguments,
> printing of line numbers and so on) you think it's better to choose the other
> option, feel free to disagree and do it the way you think is better.

I'll raise the left-over opens again the cover letter of v3, maybe we will get one
more opinion on this which helps to find the right direction. 😊

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

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

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

> I believe x86 also pushes a data entry in the shadow stack when calling the
> signal handler (the sigframe token), so couldn't GDB look for it and conclude
> that the entry following it is the "<signal handler called>"
> entry?
> 
> > 5) Remove annotations.  Based on Tom's input, I think we should drop
> > them, but I am not yet sure how exactly.  Please see my latest response
> here:
> > https://sourceware.org/pipermail/gdb-patches/2025-October/221652.html
> 
> From that thread I understood that you can simply not add annotations to
> "bt -shadow" output.
> 
> Or — and this is probably me reading between the lines — if annotations
> appear because you are reusing functions from the regular backtrace
> command and they aren't adequate, then you can ignore the problem
> because annotations are long deprecated and not expected to work for new
> functionality.

Yes, Tom convinced me to remove them. 😊
https://sourceware.org/pipermail/gdb-patches/2026-April/226410.html

Christina
Intel Deutschland GmbH
Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928