Re: Shadow Stack Locking Semantics between arch's

On Fri, 2026-08-28 at 14:27 +0100, Mark Brown wrote:

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.

If we want to have a unified API (Bill convinced me that we did, but maybe we
should have more discussion on this point), we will need to hammer out the small
differences between the arch's. For technically supported, but nonsensical
combos. I'd think to resolve the differences by not supporting them. But I mean,
it's not the end of the world. In the end we are just talking about confusing a
handful of libc developers. They can be probably handle things.

quoted

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

quoted

Oh? What was the blocker?

quoted

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.

quoted

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.

Ok, don't want to re-litigate anything. But at some point someone was talking
about a case where you needed to create a special large stack.

In general it makes sense to not add this if no one is pestering about it.