Shadow Stack Locking Semantics between arch's

[Mark Brown]

On Wed, Sep 09, 2026 at 12:57:57PM -0500, Bill Roberts wrote:

> > > unsigned long locked = 0x2; // Kernel Task State -> LOCK WRITE
> > > unsigned long cur_val = 0x3; // Kernel Task State -> WRITE and SHADOWSTACK
> > > ENABLED
> > > unsigned long new_val = 0x0; // Userspace Feature Change via syscall ->
> > > DISABLE
> > > | x86-64 | risc-v | arm64 |
> > > | ---------- | -------- | --------- |
> > > | Works  | Fails  | Fails     |

> > I would not have expected that combination to work at all with the
> > prctl() (as opposed to arch_prctl()) interface TBH, if you've locked
> > write on you shouldn't be able to disable it.  The reason that works on
> > x86 at the minute is that for x86 you can only change one bit at a time
> > so the new value when disabling is effectively 0x2, not 0x0.

> Yes, this is exactly what I am pointing out. Implementation aside, is that
> the behavior we want?

It seems more helpful to support changing more than one bit at once.

> > I think for ABI compatibility RISC-V will have to continue accepting 0
> > as being equivalent to locking PR_SHADOW_STACK_ENABLE (or everything,
> > but it only supports that one bit right now).

> TL;DR - No users, lets fix it before risc-v lands the userspace side IIUC

Oh, that would be even better if we could do that!  Thanks for checking
the userspace situation.

> > > 3. riscv should return -EPERM vs -EINVAL

> > If you mean for arch_lock_shadow_stack_status() I think -EINVAL is a
> > sensible error code when the system or task does not support shadow
> > stacks, I'm not sure we should return -EPERM at all.  On arm64 we
> > support locking any bit, not just the ones that we currently know about.
> > This is for future proofing, userspace can lock unknown flags.

> No, I mean when setting a locked bit via prctl
> and PR_SET_SHADOW_STACK_STATUS.
> Currently, the error codes for changing a locked bit:
> x86: EPERM
> arm64: EBUSY (Which we discussed offline about changing to EPERM)

Yes, I'll post a patch for that this week all being well.
-------------- 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/20260909/4298c167/attachment-0001.sig>