Re: Shadow Stack Locking Semantics between arch's

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:

quoted

On Thu, Aug 27, 2026 at 09:27:06PM +0000, Edgecombe, Rick P wrote:

quoted

quoted

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?

quoted

quoted

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)?

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

Oh? What was the blocker?

quoted

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.