lkml.org 
[lkml]   [2021]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] userfaultfd: support control over mm of remote PIDs
From
Date


> 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.
\
 
 \ /
  Last update: 2021-10-13 18:03    [W:0.102 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site