Re: [RFC PATCH] userfaultfd: support control over mm of remote PIDs

[Peter Xu <peterx@redhat.com>]

On Sun, Sep 26, 2021 at 10:06:37AM -0700, Nadav Amit wrote:
> From: Nadav Amit <namit@vmware.com>
> 
> Non-cooperative mode is useful but only for forked processes.
> Userfaultfd can be useful to monitor, debug and manage memory of remote
> processes.
> 
> To support this mode, add a new flag, UFFD_REMOTE_PID, and an optional
> second argument to the userfaultfd syscall. When the flag is set, the
> second argument is assumed to be the PID of the process that is to be
> monitored. Otherwise the flag is ignored.
> 
> The syscall enforces that the caller has CAP_SYS_PTRACE to prevent
> misuse of this feature.
> 
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Mike Rapoport <rppt@linux.vnet.ibm.com>
> Cc: Peter Xu <peterx@redhat.com>
> Signed-off-by: Nadav Amit <namit@vmware.com>

I think this patch from one pov looks just likes the other patch of the
process_madvise on DONTNEED - the new interface definitely opens new way to do
things, however IMHO it would be great to discuss some detailed scenario that
we can do with it better than the existing facilities.

The thing is uffd already provides some mechanism for doing things like
customized swapping, so that's not something new IMHO that this patch brings
(neither is what the DONTNEED patch brings), just like when I raised in the
other thread about umap.

So IMHO it'll be great if there can be some elaboration on how the "remote"
capability could help us do things better (e.g., use cases that we may not
solve with linking against another uffd-supported library, or we can't do with
register uffd then fork()).

(I skipped the security side of things, as I replied in the other thread that I
 think I buy in your point on depending on PTRACE capability and also the
 examples you gave on ptrace() and process_vm_writev() are persuasive to me,
 but no expert on that..)

Thanks,

-- 
Peter Xu