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

[Mark Brown]

On Thu, Nov 16, 2023 at 10:32:06AM +0000, Szabolcs.Nagy@xxxxxxx wrote:
> The 11/16/2023 00:52, Edgecombe, Rick P wrote:
> > On Wed, 2023-11-15 at 18:43 +0000, Mark Brown wrote:

> while CLONE_VFORK allows the child to use the parent shadow
> stack (parent and child cannot execute at the same time and
> the child wont return to frames created by the parent), we
> want to enable precise size accounting of the shadow stack
> so requesting a new shadow stack should work if new stack
> is specified.

> but stack==0 can force shadow_stack_size==0.

> i guess the tricky case is stack!=0 && shadow_stack_size==0:
> the user may want a new shadow stack with default size logic,
> or (with !CLONE_VM || CLONE_VFORK) wants to use the existing
> shadow stack from the parent.

If shadow_stack_size is 0 then we're into clone() behaviour and doing
the default/implicit handling which is to do exactly what the above
describes.

> > What is the case for stack=sp bit of the logic?

> iirc it is not documented in the clone man page what stack=0
> means and of course you don't want sp==0 in the vfork child
> so some targets sets stack to sp in vfork, others set it 0
> and expect the kernel to do the right thing.

The manual page explicitly says that not specifying a stack means to use
the same stack area as the parent.

> this likely does not apply to clone3 where the size has to be
> specified so maybe stack==sp does not need special treatment.

You'd have to be jumping through hoops to manage to get the same stack
pointer while explicitly specifying a stack with clone3() on
architectures where the stack grows down.  I'm not sure there's a
reasonable use case.

Attachment: signature.asc
Description: PGP signature