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.
signature.asc
Description: PGP signature
