On Fri, Oct 27, 2023 at 12:49:59PM +0100, Szabolcs.Nagy@arm.com wrote:
The 10/26/2023 13:40, Deepak Gupta wrote:
In general, I am assuming such placement requirements emanate because regular stack holds data (local args, etc) as well and thus software may make assumptions about how stack frame is prepared and may worry about layout and such. In case of shadow stack, it can only hold return
no. the lifetime is the issue: a stack in principle can outlive a thread and resumed even after the original thread exited. for that to work the shadow stack has to outlive the thread too.
(or the other way around: a stack can be freed before the thread exits, if the thread pivots away from that stack.)
posix threads etc. don't allow this, but the linux syscall abi (clone) does allow it.
i think it is reasonable to tie the shadow stack lifetime to the thread lifetime, but this clearly introduces a limitation on how the clone api can be used. such constraint on the userspace programming model is normally a bad decision, but given that most software (including all posix conforming code) is not affected, i think it is acceptable for an opt-in feature like shadow stack.
I tend to agree - software that's doing a lot of stack pivoting could do something like allocate a small stack with clone3() and then immediately pivoting away from it so they never actually use the stack that's tied to the thread. It's a bit clunky and wasteful but should work.
Since everyone seems OK with dealing with the placement issues by specifying size only I'm planning on sending a new version that does that after the merge window, assuming nobody else raises concerns.