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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <03C026D4-EBE8-4649-9C42-63F82941B781@gmail.com>
Date:   Wed, 13 Oct 2021 09:02:48 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     Peter Xu <peterx@...hat.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Andrea Arcangeli <aarcange@...hat.com>,
        Mike Rapoport <rppt@...ux.vnet.ibm.com>
Subject: Re: [RFC PATCH] userfaultfd: support control over mm of remote PIDs



> On Oct 12, 2021, at 7:18 PM, Peter Xu <peterx@...hat.com> wrote:
> 
> On Sun, Sep 26, 2021 at 10:06:37AM -0700, Nadav Amit wrote:
>> From: Nadav Amit <namit@...are.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@...hat.com>
>> Cc: Andrew Morton <akpm@...ux-foundation.org>
>> Cc: Mike Rapoport <rppt@...ux.vnet.ibm.com>
>> Cc: Peter Xu <peterx@...hat.com>
>> Signed-off-by: Nadav Amit <namit@...are.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.