ARM64: GCS: RET history and GCSSS1 stack switching

[Mark Brown]

On Wed, Sep 17, 2025 at 12:08:48PM +0200, Igor Svilenkov Bozic wrote:

> 1. Retired entries lingering after RETs:
> When using a GCS-aware program that pushes return addresses and then
> RETs, I noticed that the slots below the GCSPR_EL0 pointer still
> contain "retired entries" from the previous call frame(s). Is this
> leftover prior state expected as a feature, perhaps to assist
> profiling/debug tools by preserving a history of RETs?

That is the expected behaviour.  It does reduce memory traffic a bit and
I'm not sure that the history of the call stack is seen as a big
concern.  The focus is on preventing writes.

> If so, is there a stricter mode to force a wipe of the shadow stack
> after a RET, in scenarios where maximum security is preferred?

No such mode exists, you could implement it by giving yourself write
permission to the GCS but that that substantially reduces the security
benefits of GCS.

> 2. GCSSS1 usage with new stacks
> When switching to a freshly mapped GCS shadow stack, it appears that
> GCSSS1 requires jumping to an address that already contains a valid
> (completed) token, which is then consumed and replaced with an
> in-progress token.

> As a result, it's not possible to do a RET to a return address higher
> in the call stack prior to the GCSSS1 call site. For example, if the
> shadow stack switch occurs in a call chain like main() →
> subfunction(), you cannot directly RET back up to main() while the new
> stack is active. Instead, either the new stack must be manipulated
> (given that it's a writable GCS) by copying (via GCSSTR) to the newly
> switched shadow stack or by fabricating a sigframe with a new
> GCSPR_EL0 (with a proper SIGNAL_CAP) as we do in CRIU in the restore
> flow.

That sounds correct, yes.

> I've written a minimal selftest to help me get a better understanding
> of what's happening under the hood when using GCSSS1 and GCSSTR as
> well as remapping the shadow stack VMA. The test is available here:
> https://github.com/svilenkov/gcs-play

Please consider sending that upstream, especially if it's capturing
behaviour that's important for CRIU - if we've got a selftest then we'll
notice any problems that come up

> I plan to present this work done with CRIU at the Linux Plumbers
> Conference this year (Containers and Checkpoint/Restore MC). If
> there's also an Arm64 MC or any Arm-related session, I'd love to
> attend it.

Nothing Arm specific that I'm aware of, though there will be Arm people
about and we'll be taking part in some of the miniconfs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20250917/98c6e6a1/attachment.sig>