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 49FC9C00144 for ; Mon, 1 Aug 2022 22:51:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A050B8E0001; Mon, 1 Aug 2022 18:51:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 98CB26B0072; Mon, 1 Aug 2022 18:51:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 805FD8E0001; Mon, 1 Aug 2022 18:51:32 -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 6B4186B0071 for ; Mon, 1 Aug 2022 18:51:32 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 3C4F3AB957 for ; Mon, 1 Aug 2022 22:51:32 +0000 (UTC) X-FDA: 79752522024.29.AC9EC15 Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) by imf21.hostedemail.com (Postfix) with ESMTP id CDB391C0108 for ; Mon, 1 Aug 2022 22:51:31 +0000 (UTC) Received: by mail-io1-f53.google.com with SMTP id h145so9488669iof.9 for ; Mon, 01 Aug 2022 15:51:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc; bh=glcOCUJ/+awLcSG8X5QxtUVosWAHdrRlN7P8qFCy/KU=; b=VgjLNHr1hMbP7jz5VD9tM4tHHUdeWiE6jv/PZZxVCEl8oCfbeuNfGwRZv+sM+Wf2i5 oNtEEDp7KV0lDn8cKVruat3XxxQpJMcYjwbPK6y/MVRRPL11HHL0qSFaA+lfpHzZBha0 nLWIVaLCa21JIuOinIDkNS5w6493rVMBjMsIoJBEJyiHzTbqwHr8PtBHwPGlSVsZYhnF QZ0bwchCYRMq8Xg6oV57EE21VLo09Sr7nwNLOc9tMa0EkmmzqE6+UV6VMx2SxN+hUzky CnA8w+UFJxkOejBgEvFvCIaDj3nOXOQ57P4poCq6zqCOaJrsgvvPN50y3wl4tui1yenO Uz4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc; bh=glcOCUJ/+awLcSG8X5QxtUVosWAHdrRlN7P8qFCy/KU=; b=VmhM92SKiJzvvLrUIj0cnLLBCkmWSt9MHgScOTOmaSM3IwOhZ31kVDcZw+BaH4ZEz+ GNOxSWQPAZqrEPlMY1HRTrAtRapUZCzuFWhNoKi/1GV0F6ycp/K4tQArCAkiYCR68eG5 J1uTTVJ7fQ9sDcPIEEDBsDcyy3GNgltMEE2Lax08L0yo86vcQ6iRtTY2TBFFJUu55AgT 5xwxVSUoHlBPzdzoPeCWyMkjeR2/kxvZ4byEB0WmpnTuFCCg5miIXIgsg4gUcblxrhDJ w0UavhoEW7dT+ubgCqRNZ++P+/XVBhzOoIj3seo2GXzpN9kjLC5y31vXd+0Ex6oslfEB 42wg== X-Gm-Message-State: AJIora+JjbRVkqJDMZx2MAysWuUNQKNWC2UqTz3zLkYSKrxADMkxel+M i/KUOttl9d1O5vt45dut7I6lU2MBn3johezdhJrqsg== X-Google-Smtp-Source: AGRyM1uNtkg5Y2IRmGnxo1RbFLJVbjJuAEzaSRiEXHBPKJ+mQGbRVw11UEmSKc0sWqWF8C25CpekbWeNsTatl+C7xk4= X-Received: by 2002:a05:6602:15c8:b0:67c:45c7:40c9 with SMTP id f8-20020a05660215c800b0067c45c740c9mr6287785iow.138.1659394290961; Mon, 01 Aug 2022 15:51:30 -0700 (PDT) MIME-Version: 1.0 References: <20220719195628.3415852-1-axelrasmussen@google.com> <7EF50BE4-84EA-4D57-B58C-6697F1B74904@vmware.com> In-Reply-To: From: Axel Rasmussen Date: Mon, 1 Aug 2022 15:50:55 -0700 Message-ID: Subject: Re: [PATCH v4 0/5] userfaultfd: add /dev/userfaultfd for fine grained access control To: Nadav Amit Cc: "Schaufler, Casey" , Alexander Viro , Andrew Morton , Dave Hansen , "Dmitry V . Levin" , Gleb Fotengauer-Malinovskiy , Hugh Dickins , Jan Kara , Jonathan Corbet , Mel Gorman , Mike Kravetz , Mike Rapoport , Peter Xu , Shuah Khan , Suren Baghdasaryan , Vlastimil Babka , zhangyi , "linux-doc@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "linux-kselftest@vger.kernel.org" , Andrea Arcangeli Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VgjLNHr1; spf=pass (imf21.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1659394291; a=rsa-sha256; cv=none; b=U9WApZk5ereQuIZkGFN0AOk5b4y8dC6rthTOme+KFDFRWnJedb34ieaE4lYOHFZeRvFQ5m imDR5jEKhCs5FakPPo5zHjd+p0MKiTCacQnA9txL+euw54OKFGKDGH52uYTzF3/0Y/3BgE 27Px723a7jAva1y3Emq2e9DscRbY3E4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1659394291; 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=glcOCUJ/+awLcSG8X5QxtUVosWAHdrRlN7P8qFCy/KU=; b=vdLutvO3SCuqRdvgb/HAgFT+/3RtErI1zNZ5/zJNJpH8L+hPim1Kf91ba2ehzx9ETHMf0a QBNYvFClu8rfhABqO/bNCUlewDao2uFh50vTNfbqhgggG5uqnBH2zeplQd9FPqKNheuUi6 /jTnTU0kvLYsw6fJRF/twRrgseuQeNY= X-Stat-Signature: cf7nqbg8q5wntkdmosrrptyqgke6zu3i X-Rspamd-Queue-Id: CDB391C0108 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VgjLNHr1; spf=pass (imf21.hostedemail.com: domain of axelrasmussen@google.com designates 209.85.166.53 as permitted sender) smtp.mailfrom=axelrasmussen@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam04 X-HE-Tag: 1659394291-198986 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 Mon, Aug 1, 2022 at 12:53 PM Nadav Amit wrote: > > On Aug 1, 2022, at 10:13 AM, Axel Rasmussen wr= ote: > > > =E2=9A=A0 External Email > > > > I finished up some other work and got around to writing a v5 today, > > but I ran into a problem with /proc/[pid]/userfaultfd. > > > > Files in /proc/[pid]/* are owned by the user/group which started the > > process, and they don't support being chmod'ed. > > > > For the userfaultfd device, I think we want the following semantics: > > - For UFFDs created via the device, we want to always allow handling > > kernel mode faults > > - For security, the device should be owned by root:root by default, so > > unprivileged users don't have default access to handle kernel faults > > - But, the system administrator should be able to chown/chmod it, to > > grant access to handling kernel faults for this process more widely. > > > > It could be made to work like that but I think it would involve at leas= t: > > > > - Special casing userfaultfd in proc_pid_make_inode > > - Updating setattr/getattr for /proc/[pid] to meaningfully store and > > then retrieve uid/gid different from the task's, again probably > > special cased for userfautlfd since we don't want this behavior for > > other files > > > > It seems to me such a change might raise eyebrows among procfs folks. > > Before I spend the time to write this up, does this seem like > > something that would obviously be nack'ed? > > [ Please avoid top-posting in the future ] I will remember this. Gmail's default behavior is annoying. :/ > > I have no interest in making your life harder than it should be. If you > cannot find a suitable alternative, I will not fight against it. > > How about this alternative: how about following KVM usage-model? > > IOW: You open /dev/userfaultfd, but this is not the file-descriptor that = you > use for most operations. Instead you first issue an ioctl - similarly to > KVM_CREATE_VM - to get a file-descriptor for your specific process. You t= hen > use this new file-descriptor to perform your operations (read/ioctl/etc). > > This would make the fact that ioctls/reads from different processes refer= to > different contexts (i.e., file-descriptors) much more natural. > > Does it sound better? Ah, that I think is more or less what my series already proposes, if I understand you correctly. The usage is: fd =3D open(/dev/userfaultfd) /* This FD is only useful for creating new userfaultfds */ uffd =3D ioctl(fd, USERFAULTFD_IOC_NEW) /* Now you get a real uffd */ close(fd); /* No longer needed now that we have a real uffd */ /* Use uffd to register, COPY, CONTINUE, whatever */ One thing we could do now or in the future is extend USERFAULTFD_IOC_NEW to take a pid as an argument, to support creating uffds for remote processes. And then we get the benefit of permissions for /dev nodes working very naturally - they default to root, but can be configured by the sysadmin via chown/chmod, or udev rules, or whatever.