Re: [PATCH v2 3/3] x86: prefer shadow stack for producing call traces

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 08/04/2026 1:23 pm, Jan Beulich wrote:
> Shadow stacks contain little more than return addresses, and they in
> particular allow precise call traces also without FRAME_POINTER.

Do you have an example of what such a backtrace now looks like ?


> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> While the 'E' for exception frames is probably okay, I'm not overly
> happy with the 'C' (for CET). I would have preferred 'S' (for shadow),
> but we use that character already.
>
> As an alternative to suppressing output for the top level exception
> frame, adding the new code ahead of the 'R' output line (and then also
> ahead of the stack top read) could be considered.
>
> Perhaps having a printk() for the PV entry case is meaningless, for
> - no frame being pushed when entered from CPL=3 (64-bit PV),
> - no entry possible from CPL<3 (32-bit PV disabled when CET is active)?
> In which case the comment probably should just be "Bogus." and the code
> merely be "break;".

Yes, PV32 doesn't exist when CET-SS is active, and PV64 doesn't push a
frame.  regs->ssp will point to the supervisor token (IDT delivery) or
on the boundary with the regular stack (FRED).

> Quite likely a number of other uses of is_active_kernel_text() also want
> amending with in_stub().

There are very few things which can exist on a shadow stack.

1) Tokens (supervisor, restore or prev)
2) Return address
3) Old-SSP
4) Old-CS

Intel recommend not allowing code or stacks to be in the bottom 64k of
the address space to prevent type confusion between Old-CS and the other
values.  Xen matches this expectation, but it might be wise to check for
it explicitly.

Notably, we cannot ever get a value matching in_stub() (outside of
general memory corruption).

On SYSCALL/SYSENTER, SSP is set to 0, and we don't re-establish a proper
SSP until the SETSSBSY after leaving the stub.  Similarly on SYSRET, the
CLRSSBSY sets SSP to 0 too.

An NMI hitting these paths should find regs->ssp pointing at it's own
shadow stack, with an Old-SSP of 0.

~Andrew