Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain;
        charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
Subject: Re: [RFC PATCH] userfaultfd: support control over mm of remote PIDs
From:   Nadav Amit <nadav.amit@gmail.com>
In-Reply-To: <21c6a41d-3f65-6a49-f604-b75ef53d2910@redhat.com>
Date:   Mon, 27 Sep 2021 13:08:40 -0700
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Linux-MM <linux-mm@kvack.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Mike Rapoport <rppt@linux.vnet.ibm.com>,
        Peter Xu <peterx@redhat.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <75ECD9E1-4696-42CB-BD84-FF9C350BB227@gmail.com>
References: <20210926170637.245699-1-namit@vmware.com>
 <83827672-0996-4c25-9991-697ad443b6b3@redhat.com>
 <A7E15D2B-FFED-4F21-88F4-227E7228782D@gmail.com>
 <21c6a41d-3f65-6a49-f604-b75ef53d2910@redhat.com>
To:     David Hildenbrand <david@redhat.com>
Precedence: bulk


> On Sep 27, 2021, at 10:06 AM, David Hildenbrand <david@redhat.com> =
wrote:
>=20
> On 27.09.21 12:19, Nadav Amit wrote:
>>> On Sep 27, 2021, at 2:29 AM, David Hildenbrand <david@redhat.com> =
wrote:
>>>=20
>>> On 26.09.21 19:06, 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.
>>>=20
>>> What supposed to happen if the target process intents to use uffd =
itself?
>> Thanks for the quick response.
>> First, sorry that I mistakenly dropped the changes to userfaultfd.h
>> that define UFFD_REMOTE_PID.
>=20
> Didn't even notice it :)
>=20
>> As for your question: there are standard ways to deal with such =
cases,
>> similarly to when a debugged program wants to use PTRACE. One way is
>> to block the userfaultfd syscall, using seccomp. Another way is to do
>> chaining using ptrace (although using ptrace for anything is
>> challenging).
>> It is also possible to add tailor something specific to userfaultfd,
>> but I think seccomp is a good enough solution. I am open to =
suggestions.
>=20
> If we have something already in place to handle PTRACE, we'd better =
reuse what's already there. Thanks!

Just to ensure we are on the same page: I meant that this is usually
left for the user application to handle. The 2 basic solutions are to
not expose userfaultfd to the monitored process (easy using seccomp)
or to chain the two monitors (hard using ptrace).

Since ptrace is hard, in theory we can have facilities to =E2=80=9Chijack=E2=
=80=9D
a context and =E2=80=9Cinject=E2=80=9D uffd event to another monitor. I =
just think
it is a total overkill at this stage.=