On Thu, Nov 16, 2023 at 06:11:17PM +0000, Edgecombe, Rick P wrote: > Now that I've thought about it more, removing the CLONE_VFORK part of > the logic has several downsides. It is a little extra work to create > and unmap a shadow stack for an operation that is supposed to be this > limited fast thing. It does rather feel like it's defeating the point of the thing. > It also will change the SSP(let me know if anyone has a general term we > can use) for the child. So if you have like: SSP seems fine, we're already using shadow stack here. > What about a CLONE_NEW_SHSTK for clone3 that forces a new shadow stack? > So keep the existing logic, but the new flag can override the logic for > !CLONE_VM and CLONE_VFORK if the caller wants. The behavior of > shadow_stack_size is then simple. 0 means use default size, !0 means > use the passed size. No need to overload and tie up args->stack. That does seem like it cuts through the ambiguous cases. If we go for that it feels like we should require the flag when specifying a size, just to be sure that everything is clear. Though having said that we could just always allocate a shadow stack if a size is specified regardless of the flags, requiring people who want non-default behaviour to have some idea what stack size they want. I don't think I have strong opinons between having the new flag or always allocating a stack if a size is specified.
Attachment:
signature.asc
Description: PGP signature
