Re: Shadow Stack Locking Semantics between arch's

[Edgecombe, Rick P]

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

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.


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

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.