Re: [PATCH RFC RFT v2 2/5] fork: Add shadow stack support to clone3()

Mark Brown
2023-11-16T18:41:17Z

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]