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] [thread-next>] [day] [month] [year] [list]

Message-Id: <A7E15D2B-FFED-4F21-88F4-227E7228782D@gmail.com>
Date:   Mon, 27 Sep 2021 03:19:40 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     David Hildenbrand <david@...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>,
        Peter Xu <peterx@...hat.com>
Subject: Re: [RFC PATCH] userfaultfd: support control over mm of remote PIDs

> On Sep 27, 2021, at 2:29 AM, David Hildenbrand <david@...hat.com> wrote:
> 
> On 26.09.21 19:06, 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.
> 
> 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.

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.