From: Jann Horn <jannh@google.com>
To: Kees Cook <keescook@chromium.org>
Cc: Daniel Colascione <dancol@google.com>,
Tim Murray <timmurray@google.com>,
Nosh Minwalla <nosh@google.com>, Nick Kralevich <nnk@google.com>,
Lokesh Gidra <lokeshgidra@google.com>,
kernel list <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
SElinux list <selinux@vger.kernel.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Mike Rapoport <rppt@linux.ibm.com>, Peter Xu <peterx@redhat.com>,
linux-security-module <linux-security-module@vger.kernel.org>
Subject: Re: [PATCH v2 0/6] Harden userfaultfd
Date: Wed, 12 Feb 2020 17:54:35 +0100 [thread overview]
Message-ID: <CAG48ez0ogRxvCK1aCnviN+nBqp6gmbUD7NjaMKvA7bF=esAc1A@mail.gmail.com> (raw)
In-Reply-To: <202002112332.BE71455@keescook>
On Wed, Feb 12, 2020 at 8:51 AM Kees Cook <keescook@chromium.org> wrote:
> On Tue, Feb 11, 2020 at 02:55:41PM -0800, Daniel Colascione wrote:
> > Let userfaultfd opt out of handling kernel-mode faults
> > Add a new sysctl for limiting userfaultfd to user mode faults
>
> Now this I'm very interested in. Can you go into more detail about two
> things:
[...]
> - Why is this needed in addition to the existing vm.unprivileged_userfaultfd
> sysctl? (And should this maybe just be another setting for that
> sysctl, like "2"?)
>
> As to the mechanics of the change, I'm not sure I like the idea of adding
> a UAPI flag for this. Why not just retain the permission check done at
> open() and if kernelmode faults aren't allowed, ignore them? This would
> require no changes to existing programs and gains the desired defense.
> (And, I think, the sysctl value could be bumped to "2" as that's a
> better default state -- does qemu actually need kernelmode traps?)
I think this might be necessary for I/O emulation? As in, if before
getting migrated, the guest writes some data into a buffer, then the
guest gets migrated, and then while the postcopy migration stuff is
still running, the guest tells QEMU to write that data from
guest-physical memory to disk or whatever; I think in that case, QEMU
will do something like a pwrite() syscall where the userspace pointer
points into the memory area containing guest-physical memory, which
would return -EFAULT if userfaultfd was restricted to userspace
accesses.
This was described in this old presentation about why userfaultfd is
better than a SIGSEGV handler:
https://drive.google.com/file/d/0BzyAwvVlQckeSzlCSDFmRHVybzQ/view
(slide 6) (recording at https://youtu.be/pC8cWWRVSPw?t=463)
WARNING: multiple messages have this Message-ID (diff)
From: Jann Horn <jannh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
To: Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: Daniel Colascione
<dancol-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Tim Murray <timmurray-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Nosh Minwalla <nosh-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Nick Kralevich <nnk-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
Lokesh Gidra
<lokeshgidra-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
kernel list
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
SElinux list <selinux-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Andrea Arcangeli
<aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
Mike Rapoport <rppt-tEXmvtCZX7AybS5Ee8rs3A@public.gmane.org>,
Peter Xu <peterx-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
linux-security-module
<linux-security-module-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2 0/6] Harden userfaultfd
Date: Wed, 12 Feb 2020 17:54:35 +0100 [thread overview]
Message-ID: <CAG48ez0ogRxvCK1aCnviN+nBqp6gmbUD7NjaMKvA7bF=esAc1A@mail.gmail.com> (raw)
In-Reply-To: <202002112332.BE71455@keescook>
On Wed, Feb 12, 2020 at 8:51 AM Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org> wrote:
> On Tue, Feb 11, 2020 at 02:55:41PM -0800, Daniel Colascione wrote:
> > Let userfaultfd opt out of handling kernel-mode faults
> > Add a new sysctl for limiting userfaultfd to user mode faults
>
> Now this I'm very interested in. Can you go into more detail about two
> things:
[...]
> - Why is this needed in addition to the existing vm.unprivileged_userfaultfd
> sysctl? (And should this maybe just be another setting for that
> sysctl, like "2"?)
>
> As to the mechanics of the change, I'm not sure I like the idea of adding
> a UAPI flag for this. Why not just retain the permission check done at
> open() and if kernelmode faults aren't allowed, ignore them? This would
> require no changes to existing programs and gains the desired defense.
> (And, I think, the sysctl value could be bumped to "2" as that's a
> better default state -- does qemu actually need kernelmode traps?)
I think this might be necessary for I/O emulation? As in, if before
getting migrated, the guest writes some data into a buffer, then the
guest gets migrated, and then while the postcopy migration stuff is
still running, the guest tells QEMU to write that data from
guest-physical memory to disk or whatever; I think in that case, QEMU
will do something like a pwrite() syscall where the userspace pointer
points into the memory area containing guest-physical memory, which
would return -EFAULT if userfaultfd was restricted to userspace
accesses.
This was described in this old presentation about why userfaultfd is
better than a SIGSEGV handler:
https://drive.google.com/file/d/0BzyAwvVlQckeSzlCSDFmRHVybzQ/view
(slide 6) (recording at https://youtu.be/pC8cWWRVSPw?t=463)
next prev parent reply other threads:[~2020-02-12 16:55 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 22:55 [PATCH v2 0/6] Harden userfaultfd Daniel Colascione
2020-02-11 22:55 ` Daniel Colascione
2020-02-11 22:55 ` [PATCH v2 1/6] Add a new flags-accepting interface for anonymous inodes Daniel Colascione
2020-02-12 16:37 ` Stephen Smalley
2020-02-12 17:23 ` Daniel Colascione
2020-02-12 17:23 ` Daniel Colascione
2020-02-11 22:55 ` [PATCH v2 2/6] Add a concept of a "secure" anonymous file Daniel Colascione
2020-02-12 16:49 ` Stephen Smalley
2020-02-14 22:13 ` kbuild test robot
2020-02-14 22:13 ` kbuild test robot
2020-02-11 22:55 ` [PATCH v2 3/6] Teach SELinux about a new userfaultfd class Daniel Colascione
2020-02-12 17:05 ` Stephen Smalley
2020-02-12 17:19 ` Daniel Colascione
2020-02-12 18:04 ` Stephen Smalley
2020-02-12 18:04 ` Stephen Smalley
2020-02-12 18:59 ` Stephen Smalley
2020-02-12 19:04 ` Daniel Colascione
2020-02-12 19:04 ` Daniel Colascione
2020-02-12 19:11 ` Stephen Smalley
2020-02-12 19:11 ` Stephen Smalley
2020-02-12 19:13 ` Daniel Colascione
2020-02-12 19:13 ` Daniel Colascione
2020-02-12 19:17 ` Stephen Smalley
2020-02-11 22:55 ` [PATCH v2 4/6] Wire UFFD up to SELinux Daniel Colascione
2020-02-11 22:55 ` Daniel Colascione
2020-02-11 22:55 ` [PATCH v2 5/6] Let userfaultfd opt out of handling kernel-mode faults Daniel Colascione
2020-02-11 22:55 ` Daniel Colascione
2020-02-11 22:55 ` [PATCH v2 6/6] Add a new sysctl for limiting userfaultfd to user mode faults Daniel Colascione
2020-02-11 23:13 ` [PATCH v2 0/6] Harden userfaultfd Casey Schaufler
2020-02-11 23:13 ` Casey Schaufler
2020-02-11 23:27 ` Daniel Colascione
2020-02-12 16:09 ` Stephen Smalley
2020-02-21 17:56 ` James Morris
2020-02-12 7:50 ` Kees Cook
2020-02-12 7:50 ` Kees Cook
2020-02-12 16:54 ` Jann Horn [this message]
2020-02-12 16:54 ` Jann Horn
2020-02-12 17:14 ` Peter Xu
2020-02-12 19:41 ` Andrea Arcangeli
2020-02-12 19:41 ` Andrea Arcangeli
2020-02-12 20:04 ` Daniel Colascione
2020-02-12 23:41 ` Andrea Arcangeli
2020-02-12 17:12 ` Daniel Colascione
2020-02-12 17:12 ` Daniel Colascione
2020-02-14 3:26 ` [PATCH 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione
2020-02-14 3:26 ` [PATCH 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione
2020-02-14 3:26 ` [PATCH 2/3] Teach SELinux about anonymous inodes Daniel Colascione
2020-02-14 16:39 ` Stephen Smalley
2020-02-14 17:21 ` Daniel Colascione
2020-02-14 18:02 ` Stephen Smalley
2020-02-14 18:08 ` Stephen Smalley
2020-02-14 20:24 ` Stephen Smalley
2020-02-14 3:26 ` [PATCH 3/3] Wire UFFD up to SELinux Daniel Colascione
2020-03-25 23:02 ` [PATCH v2 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione
2020-03-25 23:02 ` [PATCH v2 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione
2020-03-26 13:53 ` Stephen Smalley
2020-03-25 23:02 ` [PATCH v2 2/3] Teach SELinux about anonymous inodes Daniel Colascione
2020-03-26 13:58 ` Stephen Smalley
2020-03-26 17:59 ` Daniel Colascione
2020-03-26 17:37 ` Stephen Smalley
2020-03-25 23:02 ` [PATCH v2 3/3] Wire UFFD up to SELinux Daniel Colascione
2020-03-25 23:49 ` Casey Schaufler
2020-03-26 18:14 ` [PATCH v3 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione
2020-03-26 18:14 ` [PATCH v3 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione
2020-03-26 19:00 ` Stephen Smalley
2020-03-26 18:14 ` [PATCH v3 2/3] Teach SELinux about anonymous inodes Daniel Colascione
2020-03-26 19:02 ` Stephen Smalley
2020-03-26 18:14 ` [PATCH v3 3/3] Wire UFFD up to SELinux Daniel Colascione
2020-03-26 20:06 ` [PATCH v4 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione
2020-03-26 20:06 ` [PATCH v4 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione
2020-03-27 13:40 ` Stephen Smalley
2020-03-26 20:06 ` [PATCH v4 2/3] Teach SELinux about anonymous inodes Daniel Colascione
2020-03-27 13:41 ` Stephen Smalley
2020-03-26 20:06 ` [PATCH v4 3/3] Wire UFFD up to SELinux Daniel Colascione
2020-04-01 21:39 ` [PATCH v5 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione
2020-04-01 21:39 ` [PATCH v5 1/3] Add a new LSM-supporting anonymous inode interface Daniel Colascione
2020-05-07 16:02 ` James Morris
2020-08-04 21:22 ` Eric Biggers
2020-04-01 21:39 ` [PATCH v5 2/3] Teach SELinux about anonymous inodes Daniel Colascione
2020-04-01 21:39 ` [PATCH v5 3/3] Wire UFFD up to SELinux Daniel Colascione
2020-08-04 21:16 ` Eric Biggers
2020-04-13 13:29 ` [PATCH v5 0/3] SELinux support for anonymous inodes and UFFD Daniel Colascione
2020-04-22 16:55 ` James Morris
2020-04-22 17:12 ` Casey Schaufler
2020-04-23 22:24 ` Casey Schaufler
2020-04-27 16:18 ` Casey Schaufler
2020-04-27 16:48 ` Stephen Smalley
2020-04-27 17:12 ` Casey Schaufler
2020-04-29 17:02 ` Stephen Smalley
2020-04-27 17:15 ` Casey Schaufler
2020-04-27 19:40 ` Stephen Smalley
2020-06-04 3:56 ` James Morris
2020-06-04 18:51 ` Stephen Smalley
2020-06-04 19:24 ` Lokesh Gidra
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='CAG48ez0ogRxvCK1aCnviN+nBqp6gmbUD7NjaMKvA7bF=esAc1A@mail.gmail.com' \
--to=jannh@google.com \
--cc=aarcange@redhat.com \
--cc=dancol@google.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=lokeshgidra@google.com \
--cc=nnk@google.com \
--cc=nosh@google.com \
--cc=peterx@redhat.com \
--cc=rppt@linux.ibm.com \
--cc=selinux@vger.kernel.org \
--cc=timmurray@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.