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:

quoted

On Tue, Sep 02, 2025 at 11:21:48AM +0100, Mark Brown wrote:

quoted

+	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);

quoted

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@arm.com>