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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 904FEC43334 for ; Wed, 20 Jul 2022 20:10:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CDA006B0072; Wed, 20 Jul 2022 16:10:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C8B206B0073; Wed, 20 Jul 2022 16:10:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B51126B0074; Wed, 20 Jul 2022 16:10:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id A4EA46B0072 for ; Wed, 20 Jul 2022 16:10:50 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 6C2ECA04B9 for ; Wed, 20 Jul 2022 20:10:50 +0000 (UTC) X-FDA: 79708571460.05.94974F1 Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) by imf05.hostedemail.com (Postfix) with ESMTP id 00085100073 for ; Wed, 20 Jul 2022 20:10:49 +0000 (UTC) Received: by mail-io1-f53.google.com with SMTP id h145so15186060iof.9 for ; Wed, 20 Jul 2022 13:10:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZbB9VnKGJLInuj72DJYZA8o4PYITUT0S6KGJae4KPqw=; b=D3g2EvZhuWnUXeQaneJXywswhO2BPfAAtNguy0zp2A5RQItolJnZk+5TXzZbLv22J1 mgwTY9bypAkjnMaz34meIe4XYXvZEnmOoomJmHTnzEgxrk6NXJG1vrRNb9e847rKDeV8 qxxOp4Gc5r/Gs0OLVXncyreX8GBO7cxWV65zKQ4bGnac+El3rxT+tWLiEf0ZHBsJHYlR 6SkBlISbeozFHbHXgBEnh4FCjPST5VEvVPQ7B9cg9z6F+dcDc0MFObTNzM/boZagIwGf pDxWTHY+8z+Zw/nICI4UG50b1mcX2d/9YMN8DrFDX7ZuNLaGsOnKrL/fptVQs6Xbi7xg +Ydg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZbB9VnKGJLInuj72DJYZA8o4PYITUT0S6KGJae4KPqw=; b=sFVu4t4OkFi4FQjiWrwShAsbyVDFxKnsGEH8voFymKykytCMJ5/C5f4xU3p3kIl2LX vIP9/5GrPCtINUh/qIAC0jlPSSMCcNd9/qqtk83l/duPWBG0z1H5D5KFmYWFR+2CZiGT OaKykyg4a6cXTzzpJ3SlfRJWASWQ1MbXX1ICj71cTij0qAamieadV1XRHwQff6VoruLg OggOwAsHdg1js9dIJhIE+ZfN14d8dVNa9pXLo5c++E8o2t8dFEIW2r5jvbG99xYJLQfh bUUL/bONcriYK4DigcBFuZMII1/f/dC6JSZdtdcFUKr4B62p8tOpPDaxBsY4CFn01AV9 REiA== X-Gm-Message-State: AJIora9wl1f8K+r762XMSl4hddaZTjkIvY4Y41c5qeAcWf6JerKx4for 1znDQZgQsUaBzYLCz8euvqL+GrkJVHZ5OLjdqUKTyQ== X-Google-Smtp-Source: AGRyM1vzHpiGlGt2/iCzYwHXXGPDjI8Pd2dtU3rTuyBSy1cuI2Exos8o8s6qqTFWtm7HAQDTBB7j+C6oDcLY75bACzY= X-Received: by 2002:a02:c812:0:b0:33f:4812:4699 with SMTP id p18-20020a02c812000000b0033f48124699mr19570572jao.314.1658347849186; Wed, 20 Jul 2022 13:10:49 -0700 (PDT) MIME-Version: 1.0 References: <20220719195628.3415852-1-axelrasmussen@google.com> <20220719195628.3415852-3-axelrasmussen@google.com> <3C93275E-B3B8-45CA-808E-0C163DBBB32F@vmware.com> In-Reply-To: <3C93275E-B3B8-45CA-808E-0C163DBBB32F@vmware.com> From: Axel Rasmussen Date: Wed, 20 Jul 2022 13:10:13 -0700 Message-ID: Subject: Re: [PATCH v4 2/5] userfaultfd: add /dev/userfaultfd for fine grained access control To: Nadav Amit Cc: Peter Xu , Alexander Viro , Andrew Morton , Dave Hansen , "Dmitry V . Levin" , Gleb Fotengauer-Malinovskiy , Hugh Dickins , Jan Kara , Jonathan Corbet , Mel Gorman , Mike Kravetz , Mike Rapoport , Shuah Khan , Suren Baghdasaryan , Vlastimil Babka , zhangyi , "linux-doc@vger.kernel.org" , linux-fsdevel , LKML , Linux MM , "linux-kselftest@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=D3g2EvZh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=axelrasmussen@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1658347850; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ZbB9VnKGJLInuj72DJYZA8o4PYITUT0S6KGJae4KPqw=; b=1YXLv17lebNhoAdoP2LoVZP+00O7oqZSekI+Rz8Dxyxvi3M/swt0WGqsJitHY04IzePFUC VQB+A8O1DtTOhvGDOCDL7U0zC3A/Mv3umi/NJPBfCea6P2Ec4qSP83aYy4OCxLcLv+AnwB 8g4rsyDxsmEKP3mKYIjulkrP7ubxla4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1658347850; a=rsa-sha256; cv=none; b=C2WgYrirSan++xKzur/8HMD1otTDwZkD+sKz9+5yOD+aKPpls7WqfM30UbdDA+AHuffxyK /OvoUC/BOD2N2bRgGMmTeZVSN+KMXpT9CvH7ehoLx3REG4FObRHG09E0gbgWP5VcW8JdGH QL6XTsWY85dFB23q5QyOjO4n3l6o3Eo= X-Stat-Signature: 1wcitxfojqncyauanffackkum6wwcd1s X-Rspamd-Queue-Id: 00085100073 X-Rspamd-Server: rspam08 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=D3g2EvZh; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=axelrasmussen@google.com X-Rspam-User: X-HE-Tag: 1658347849-661466 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 Wed, Jul 20, 2022 at 10:42 AM Nadav Amit wrote: > > On Jul 19, 2022, at 7:32 PM, Peter Xu wrote: > > > =E2=9A=A0 External Email > > > > On Tue, Jul 19, 2022 at 11:55:21PM +0000, Nadav Amit wrote: > >> Anyhow, I do want to clarify a bit about the =E2=80=9Ccross-process su= pport=E2=80=9D > >> userfaultfd situation. Basically, you can already get cross-process su= pport > >> today, by using calling userfaultfd() on the controlled process and ca= lling > >> pidfd_open() from another process. It does work and I do not remember = any > >> issues that it introduced (in contrast, for instance, to io-uring, tha= t > >> would break if you use userfaultfd+iouring+fork today). > > > > Do you mean to base it on pidof_getfd()? > > autocorrect? :) > > I did refer to pidfd_getfd() as a syscall that can be used today by one > process to control the address space of another process. I did not intend= to > use it for the actual implementation. > > > Just want to mention that this will still need collaboration of the tar= get > > process as userfaultfd needs to be created explicitly there. From that= POV > > it's still more similar to general SCM_RIGHTS trick to pass over the fd= but > > just to pass it in a different way. > > There are also some tricks you can do with ptrace in order not to need th= e > collaboration, but they are admittedly fragile. > > > IMHO the core change about having /proc/pid/userfaultfd is skipping tha= t > > only last step to create the handle. > > Yes. The point that I was trying to make is that there are no open issues > with adding support for remote process control through > /proc/pid/userfaultfd. This is in contrast, for example, for using io-uri= ng > with userfaultfd. For instance, if you try to use io-uring TODAY with > userfaultfd (without the async support that I need to add), and you try t= o > monitor the fork event, things would break (the new userfaultfd file > descriptor after fork would be installed on the io-worker thread). > > This is all to say that it is really simple to add support for one proces= s > monitoring userfaultfd of another process, since I understood that Axel h= ad > concerned that this might be utterly broken=E2=80=A6 Mostly I was worried it would be nontrivial to implement, and it isn't a use case I plan to use so I was hoping to ignore it and defer it to some future patches. ;) But, if it "just works" I'm happy to include it in v5.