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