Shadow Stack Locking Semantics between arch's

[Mark Brown]

On Fri, Aug 28, 2026 at 04:48:36PM +0000, Edgecombe, Rick P wrote:
> On Fri, 2026-08-28 at 14:27 +0100, Mark Brown wrote:

> > Yeah, it is.  I can't think why someone would ask for that either, but
> > equally it's more work to explicitly have a list of combinations we
> > reject for policy reasons.  At least on arm64 each permission just comes
> > down to a separate bit in a control register so they're fully
> > independent all the way down to the hardware.

> If we want to have a unified API (Bill convinced me that we did, but maybe we
> should have more discussion on this point), we will need to hammer out the small
> differences between the arch's. For technically supported, but nonsensical
> combos. I'd think to resolve the differences by not supporting them. But I mean,
> it's not the end of the world. In the end we are just talking about confusing a
> handful of libc developers. They can be probably handle things.

I think it's similar to differences due to architecture features - only
arm64 supports _PUSH because it's the only one with that feature, users
will have to work out something to do about that.  If someone has a
burning desire to lock weird feature combinations that can't be provided
everywhere they'll have similar issues but I don't see much benefit in
writing code we don't need to.  We should specify what happens if the
architecture can't do what was asked (return -EINVAL?) but I think it's
reasonable to allow the exact restrictions to vary so long as the
sensible cases all work.
-------------- 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/20260828/de5fe34b/attachment-0001.sig>