Re: [PATCH v20 4/8] fork: Add shadow stack support to clone3()

[Catalin Marinas]

On Wed, Sep 03, 2025 at 11:01:05AM +0100, Mark Brown wrote:
> On Tue, Sep 02, 2025 at 10:02:07PM +0100, Catalin Marinas wrote:
> > On Tue, Sep 02, 2025 at 11:21:48AM +0100, Mark Brown wrote:
> > > +	mmap_read_lock(mm);
> > > +
> > > +	addr = untagged_addr_remote(mm, args->shadow_stack_token);
> > > +	page = get_user_page_vma_remote(mm, addr, FOLL_FORCE | FOLL_WRITE,
> > > +					&vma);
> 
> > However, I wonder whether it makes sense to use the remote mm access
> > here at all. Does this code ever run without CLONE_VM? If not, this is
> > all done within the current mm context.
> 
> Yes, userspace can select if it wants CLONE_VM or not so we should
> handle that case.  We discussed this on prior versions and we felt that
> while we couldn't immediately see the use case for !CLONE_VM there
> wasn't a good reason to restrict the creativity of userspace developers,
> and given that you can specify the regular stack in these cases it seems
> logical that you'd also be able to specify the shadow stack.

Yeah. Not sure it makes much sense in practice but if we allow a new
stack without CLONE_VM, we should also allow a shadow stack. Thanks for
the clarification.

Reviewed-by: Catalin Marinas <catalin.marinas@xxxxxxx>