Re: Shadow Stack Locking Semantics between arch's

Mark Brown <[email protected]> Thu, 27 Aug 2026 22:41:45 +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 Thu, Aug 27, 2026 at 09:27:06PM +0000, Edgecombe, Rick P wrote:
> On Thu, 2026-08-27 at 19:14 +0100, Mark Brown wrote:
> > On Thu, Aug 27, 2026 at 12:52:28PM -0500, Bill Roberts wrote:

> > > I am proposing and have questions over the following:
> > > 1. What should the behavior be if you had write locked and disable the
> > > shadow stack?
> > >   - I can argue both ways here, -EPERM or success. I think I and most arches
> > > lead to failure.

> > Given that RISC-V doesn't support control of writes it's moot there
> > at the minute, and x86 currently uses arch_prctl() so will need an
> > additional API, it seems the path of least resistance is to allow it.
> > This also avoids locking writes (or pushes, for arm64) on effectively
> > also locking enable which seems neater.

> Hmm. I can't think of a reason to lock writes and not lock shadow stack too.
> Given likely no one is doing this, I wonder if we could change x86's behavior to
> match the others?

> The API would makes more sense to prevent disabling shadow stack if writes were
> enabled. It could return an EINVAL regardless if it is locked or not? Is that
> the arm behavior (forgetting about locked)?

arm64 currently treats each bit independently for simplicity.  The main
use case I see for actually doing that is for preventing enabling writes
or pushes, though in practice I'd expect something doing locks to just
fully lock everything after having enabled the shadow stack.  We can compose
the features easily enough so it seemed most straightforward to just let
userspace decide what it wants, it keeps the implementation simpler.

> > It has been on my list to look at this
> > repitition at some point, it had been held up by the clone3() stuff but
> > that seems to have died a death for now.

> Oh? What was the blocker?

Basically the glibc people weren't convinced they'd ever want to reuse a
shadow stack at which point having the kernel free and reallocate each time
is just as easy.  It saves having to handle corner cases with threads that
didn't exit cleanly.

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

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