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

[Nadav Amit <nadav.amit@gmail.com>]

> On Oct 12, 2021, at 7:18 PM, Peter Xu <peterx@redhat.com> wrote:
> 
> 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..)

Fair enough. Let me get back to you once I can provide more data.

For now, I just ask you to have this patch in the back of your mind if any
other change to userfaultfd syscall is proposed to prevent a potential
conflict.