On Wed, Aug 14, 2024 at 10:38:54AM +0100, Catalin Marinas wrote: > On Tue, Aug 13, 2024 at 07:58:26PM +0100, Mark Brown wrote: > > ISTR the concerns were around someone being clever with vfork() but I > > don't remember anything super concrete. In terms of the inconsistency > > here that was actually another thing that came up - if userspace > > specifies a stack for clone3() it'll just get used even with CLONE_VFORK > > so it seemed to make sense to do the same thing for the shadow stack. > > This was part of the thinking when we were looking at it, if you can > > specify a regular stack you should be able to specify a shadow stack. > Yes, I agree. But by this logic, I was wondering why the current clone() > behaviour does not allocate a shadow stack when a new stack is > requested with CLONE_VFORK. That's rather theoretical though and we may > not want to change the ABI. The default for vfork() is to reuse both the normal and shadow stacks, clone3() does make it all much more flexible. All the shadow stack ABI predates clone3(), even if it ended up getting merged after. > Anyway, I understood this patch now and the ABI decisions. FWIW: > Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx> Thanks!
Attachment:
signature.asc
Description: PGP signature
