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>
