Re: Shadow Stack Locking Semantics between arch's

Mark Brown <[email protected]> Fri, 28 Aug 2026 14:27:01 +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 10:37:45PM +0000, Edgecombe, Rick P wrote:
> On Thu, 2026-08-27 at 22:41 +0100, Mark Brown wrote:
> > On Thu, Aug 27, 2026 at 09:27:06PM +0000, Edgecombe, Rick P wrote:

> > > 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.

> Locking writes as off makes sense to me. But locking writes on, while leaving
> shadow stack unlocked. I'm not sure why you would do that. I thought that was
> Bill's scenario.

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.

> > > > 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.

> I thought it was also because they wanted finer grained control of stack sizes
> too? But yea, if no libc wants it, it's a hard sell.

They'd rather have just a size control for that, probably a process wide
control would be most useful since it's likely to be the same number for
all threads.  I suspect the main use casse would be someone trying to do
green threads, where there's an extra real thread being created.

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

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