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

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

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.

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

> 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
by GDB>".

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

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

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.

-- 
Thiago