From: Mike Rapoport <rppt@kernel.org>
To: Axel Rasmussen <axelrasmussen@google.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
"Dmitry V . Levin" <ldv@altlinux.org>,
Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>,
Hugh Dickins <hughd@google.com>, Jan Kara <jack@suse.cz>,
Jonathan Corbet <corbet@lwn.net>,
Mel Gorman <mgorman@techsingularity.net>,
Mike Kravetz <mike.kravetz@oracle.com>,
Nadav Amit <namit@vmware.com>, Peter Xu <peterx@redhat.com>,
Shuah Khan <shuah@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>, zhangyi <yi.zhang@huawei.com>,
linux-doc@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, linux-security-module@vger.kernel.org
Subject: Re: [PATCH v5 2/5] userfaultfd: add /dev/userfaultfd for fine grained access control
Date: Thu, 11 Aug 2022 09:37:25 +0300 [thread overview]
Message-ID: <YvSjpYOM4m5JG0xQ@kernel.org> (raw)
In-Reply-To: <20220808175614.3885028-3-axelrasmussen@google.com>
On Mon, Aug 08, 2022 at 10:56:11AM -0700, Axel Rasmussen wrote:
> Historically, it has been shown that intercepting kernel faults with
> userfaultfd (thereby forcing the kernel to wait for an arbitrary amount
> of time) can be exploited, or at least can make some kinds of exploits
> easier. So, in 37cd0575b8 "userfaultfd: add UFFD_USER_MODE_ONLY" we
> changed things so, in order for kernel faults to be handled by
> userfaultfd, either the process needs CAP_SYS_PTRACE, or this sysctl
> must be configured so that any unprivileged user can do it.
>
> In a typical implementation of a hypervisor with live migration (take
> QEMU/KVM as one such example), we do indeed need to be able to handle
> kernel faults. But, both options above are less than ideal:
>
> - Toggling the sysctl increases attack surface by allowing any
> unprivileged user to do it.
>
> - Granting the live migration process CAP_SYS_PTRACE gives it this
> ability, but *also* the ability to "observe and control the
> execution of another process [...], and examine and change [its]
> memory and registers" (from ptrace(2)). This isn't something we need
> or want to be able to do, so granting this permission violates the
> "principle of least privilege".
>
> This is all a long winded way to say: we want a more fine-grained way to
> grant access to userfaultfd, without granting other additional
> permissions at the same time.
>
> To achieve this, add a /dev/userfaultfd misc device. This device
> provides an alternative to the userfaultfd(2) syscall for the creation
> of new userfaultfds. The idea is, any userfaultfds created this way will
> be able to handle kernel faults, without the caller having any special
> capabilities. Access to this mechanism is instead restricted using e.g.
> standard filesystem permissions.
>
> Acked-by: Nadav Amit <namit@vmware.com>
> Acked-by: Peter Xu <peterx@redhat.com>
> Signed-off-by: Axel Rasmussen <axelrasmussen@google.com>
Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> ---
> fs/userfaultfd.c | 73 +++++++++++++++++++++++++-------
> include/uapi/linux/userfaultfd.h | 4 ++
> 2 files changed, 61 insertions(+), 16 deletions(-)
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2022-08-11 6:38 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-08 17:56 [PATCH v5 0/5] userfaultfd: add /dev/userfaultfd for fine grained access control Axel Rasmussen
2022-08-08 17:56 ` [PATCH v5 1/5] selftests: vm: add hugetlb_shared userfaultfd test to run_vmtests.sh Axel Rasmussen
2022-08-08 17:56 ` [PATCH v5 2/5] userfaultfd: add /dev/userfaultfd for fine grained access control Axel Rasmussen
2022-08-11 6:37 ` Mike Rapoport [this message]
2022-08-08 17:56 ` [PATCH v5 3/5] userfaultfd: selftests: modify selftest to use /dev/userfaultfd Axel Rasmussen
2022-08-11 6:38 ` Mike Rapoport
2022-08-17 19:53 ` Axel Rasmussen
2022-08-08 17:56 ` [PATCH v5 4/5] userfaultfd: update documentation to describe /dev/userfaultfd Axel Rasmussen
2022-08-11 6:49 ` Mike Rapoport
2022-08-08 17:56 ` [PATCH v5 5/5] selftests: vm: add /dev/userfaultfd test cases to run_vmtests.sh Axel Rasmussen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YvSjpYOM4m5JG0xQ@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=corbet@lwn.net \
--cc=dave.hansen@linux.intel.com \
--cc=glebfm@altlinux.org \
--cc=hughd@google.com \
--cc=jack@suse.cz \
--cc=ldv@altlinux.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=mgorman@techsingularity.net \
--cc=mike.kravetz@oracle.com \
--cc=namit@vmware.com \
--cc=peterx@redhat.com \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=viro@zeniv.linux.org.uk \
--cc=yi.zhang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).