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.
