Re: Shadow Stack Locking Semantics between arch's

Mark Brown <[email protected]> Fri, 28 Aug 2026 18:11:33 +0100

Newsgroups	org.infradead.lists.linux-riscv,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-api,org.kernel.vger.linux-hardening,org.kernel.vger.linux-kernel
Message-ID	<[email protected]>

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.

_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv

signature.asc (application/pgp-signature, 488 B)