On Fri, Oct 27, 2023 at 12:49:59PM +0100, Szabolcs.Nagy@xxxxxxx 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.
Attachment:
signature.asc
Description: PGP signature
