From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5CCFAC433F5 for ; Mon, 27 Sep 2021 20:08:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0790061157 for ; Mon, 27 Sep 2021 20:08:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0790061157 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 996EB6B0071; Mon, 27 Sep 2021 16:08:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 947256B0072; Mon, 27 Sep 2021 16:08:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8369E6B0073; Mon, 27 Sep 2021 16:08:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0130.hostedemail.com [216.40.44.130]) by kanga.kvack.org (Postfix) with ESMTP id 75B916B0071 for ; Mon, 27 Sep 2021 16:08:44 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 3A1C82D4C1 for ; Mon, 27 Sep 2021 20:08:44 +0000 (UTC) X-FDA: 78634441368.11.9FDFA19 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf12.hostedemail.com (Postfix) with ESMTP id DC3B110000AC for ; Mon, 27 Sep 2021 20:08:43 +0000 (UTC) Received: by mail-pf1-f173.google.com with SMTP id g14so16954164pfm.1 for ; Mon, 27 Sep 2021 13:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7vfeR4njAq3wig4eIDg5vJWu2BlZRMH3u0oFW9QEQ9w=; b=SsW7qCUbROeP/CRGUzOa/Br/izmzwYUvqgGPPapsOJUFectwunG0+JKeVS650qdteG sIK2gOB+Aj+Z2DH2JSqei6vvko+R2+RJScrsFzHb0Rzr++1I2yxjtpdSIo/7LvVHJkVL mYOFe8MSLVBMO61BUfnBzNBKb7myMOqT5cMJIZXTlee2Qw8jp1hl+30JJxmg9aYLyITs MFQvQkFPtRcW9mVy+6bpQ4Qrts5XKxte0gRcfqQlcY+XKenStsQRqX4bnc3dU9jpK1TU IyiDnYzjMzVGcInhPec7jUHvXInfc5MCIgBacugdGOeQT+9tEkeRzDJoWZc9y85ju68M fJIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7vfeR4njAq3wig4eIDg5vJWu2BlZRMH3u0oFW9QEQ9w=; b=HGMCo8jYXm+UXOxRq6zq9Vkb1o2dBLYIx+uXni/6GysaRl5MVNBUXomkHDyeso1RNs 9ePu5yTE0qz9G+Qz7bS2hmRUkEm613yjBMpMDaXyAw0+HvX25J37FmiuipkHpzWB7lX/ 909QYxDM3R/I1zRmBqbuOt+8IMwyjt0tpudOJ8SLtQjBtGeY+M9FA1Eg3fYe06HJ+3qe 20rXOO4sNg74XbRfZKrd3P7RDVcT721RvX53wlKNsfAfbDaIOcfm5zrPqSISjl65GLKM qSQqPwU2f70MCWrt8FGfphtSwcMrnr2gh0GSZW4GzPjOFwFeR+WqRQSa+esIPGvX/8QR CNCg== X-Gm-Message-State: AOAM5306X80tueCiGwvvZFicdeMr9JKRkKWHQYjm1+z0MDY/ETjOHo7x 1dbkup16GXmjvWp0sJCMtpQ= X-Google-Smtp-Source: ABdhPJxMhzemCh6titSeULgvX9XVFW7lxrKL7aHyl30hKz1EKVwHYkX4MyOwF6b6eKltSLRKeac3TQ== X-Received: by 2002:a62:1b92:0:b0:3eb:3f92:724 with SMTP id b140-20020a621b92000000b003eb3f920724mr1517989pfb.3.1632773322625; Mon, 27 Sep 2021 13:08:42 -0700 (PDT) Received: from smtpclient.apple (c-24-6-216-183.hsd1.ca.comcast.net. [24.6.216.183]) by smtp.gmail.com with ESMTPSA id i27sm17941840pfq.184.2021.09.27.13.08.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Sep 2021 13:08:42 -0700 (PDT) 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 In-Reply-To: <21c6a41d-3f65-6a49-f604-b75ef53d2910@redhat.com> Date: Mon, 27 Sep 2021 13:08:40 -0700 Cc: Andrew Morton , Linux-MM , Linux Kernel Mailing List , Andrea Arcangeli , Mike Rapoport , Peter Xu 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> <21c6a41d-3f65-6a49-f604-b75ef53d2910@redhat.com> To: David Hildenbrand X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: DC3B110000AC X-Stat-Signature: aijnpd5n8jzmoddsmqtyiiep9z5fpf1c Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=SsW7qCUb; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf12.hostedemail.com: domain of nadav.amit@gmail.com designates 209.85.210.173 as permitted sender) smtp.mailfrom=nadav.amit@gmail.com X-HE-Tag: 1632773323-541963 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Sep 27, 2021, at 10:06 AM, David Hildenbrand = wrote: >=20 > On 27.09.21 12:19, Nadav Amit wrote: >>> On Sep 27, 2021, at 2:29 AM, David Hildenbrand = wrote: >>>=20 >>> On 26.09.21 19:06, Nadav Amit wrote: >>>> From: Nadav Amit >>>> 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.=