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
