linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Mike Kravetz <mike.kravetz@oracle.com>
Cc: linux-kernel@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
	Hugh Dickins <hughd@google.com>,
	Luis Chamberlain <mcgrof@kernel.org>,
	Maxime Coquelin <maxime.coquelin@redhat.com>,
	kvm@vger.kernel.org, Jerome Glisse <jglisse@redhat.com>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Martin Cracauer <cracauer@cons.org>,
	Denis Plotnikov <dplotnikov@virtuozzo.com>,
	linux-mm@kvack.org, Marty McFadden <mcfadden8@llnl.gov>,
	Maya Gokhale <gokhale2@llnl.gov>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Mike Rapoport <rppt@linux.vnet.ibm.com>,
	Kees Cook <keescook@chromium.org>, Mel Gorman <mgorman@suse.de>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	linux-fsdevel@vger.kernel.org,
	"Dr . David Alan Gilbert" <dgilbert@redhat.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH 0/3] userfaultfd: allow to forbid unprivileged users
Date: Wed, 13 Mar 2019 14:00:23 +0800	[thread overview]
Message-ID: <20190313060023.GD2433@xz-x1> (raw)
In-Reply-To: <58e63635-fc1b-cb53-a4d1-237e6b8b7236@oracle.com>

On Tue, Mar 12, 2019 at 12:59:34PM -0700, Mike Kravetz wrote:
> On 3/11/19 2:36 AM, Peter Xu wrote:
> > 
> > The "kvm" entry is a bit special here only to make sure that existing
> > users like QEMU/KVM won't break by this newly introduced flag.  What
> > we need to do is simply set the "unprivileged_userfaultfd" flag to
> > "kvm" here to automatically grant userfaultfd permission for processes
> > like QEMU/KVM without extra code to tweak these flags in the admin
> > code.
> 
> Another user is Oracle DB, specifically with hugetlbfs.  For them, we would
> like to add a special case like kvm described above.  The admin controls
> who can have access to hugetlbfs, so I think adding code to the open
> routine as in patch 2 of this series would seem to work.

Yes I think if there's an explicit and safe place we can hook for
hugetlbfs then we can do the similar trick as KVM case.  Though I
noticed that we can not only create hugetlbfs files under the
mountpoint (which the admin can control), but also using some other
ways.  The question (of me... sorry if it's a silly one!) is whether
all other ways to use hugetlbfs is still under control of the admin.
One I know of is memfd_create() which seems to be doable even as
unprivileged users.  If so, should we only limit the uffd privilege to
those hugetlbfs users who use the mountpoint directly?

Another question is about fork() of privileged processes - for KVM we
only grant privilege for the exact process that opened the /dev/kvm
node, and the privilege will be lost for any forked childrens.  Is
that the same thing for OracleDB/Hugetlbfs?

> 
> However, I can imagine more special cases being added for other users.  And,
> once you have more than one special case then you may want to combine them.
> For example, kvm and hugetlbfs together.

It looks fine to me if we're using MMF_USERFAULTFD_ALLOW flag upon
mm_struct, since that seems to be a very general flag that can be used
by anything we want to grant privilege for, not only KVM?

Thanks,

-- 
Peter Xu

  reply	other threads:[~2019-03-13  6:00 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-11  9:36 [PATCH 0/3] userfaultfd: allow to forbid unprivileged users Peter Xu
2019-03-11  9:36 ` [PATCH 1/3] userfaultfd/sysctl: introduce unprivileged_userfaultfd Peter Xu
2019-03-12  6:58   ` Mike Rapoport
2019-03-12 12:26     ` Peter Xu
2019-03-12 13:53       ` Mike Rapoport
2019-03-11  9:37 ` [PATCH 2/3] kvm/mm: introduce MMF_USERFAULTFD_ALLOW flag Peter Xu
2019-03-11  9:37 ` [PATCH 3/3] userfaultfd: apply unprivileged_userfaultfd check Peter Xu
2019-03-11  9:58   ` Peter Xu
2019-03-12  7:01 ` [PATCH 0/3] userfaultfd: allow to forbid unprivileged users Mike Rapoport
2019-03-12 12:29   ` Peter Xu
2019-03-12  7:49 ` Kirill A. Shutemov
2019-03-12 12:43   ` Peter Xu
2019-03-12 19:59 ` Mike Kravetz
2019-03-13  6:00   ` Peter Xu [this message]
2019-03-13  8:22     ` Paolo Bonzini
2019-03-13 18:52       ` Andrea Arcangeli
2019-03-13 19:12         ` Paolo Bonzini
2019-03-13 23:44           ` Andrea Arcangeli
2019-03-14 10:58             ` Paolo Bonzini
2019-03-14 15:23               ` Alexei Starovoitov
2019-03-14 16:00                 ` Paolo Bonzini
2019-03-14 16:16               ` Andrea Arcangeli
2019-03-15 16:09                 ` Kees Cook
2019-03-13 20:01         ` Mike Kravetz
2019-03-13 23:55           ` Andrea Arcangeli
2019-03-14  3:32             ` Mike Kravetz
2019-03-13 17:50     ` Mike Kravetz
2019-03-15  8:26       ` Peter Xu

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=20190313060023.GD2433@xz-x1 \
    --to=peterx@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=cracauer@cons.org \
    --cc=dgilbert@redhat.com \
    --cc=dplotnikov@virtuozzo.com \
    --cc=gokhale2@llnl.gov \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=jglisse@redhat.com \
    --cc=keescook@chromium.org \
    --cc=kirill@shutemov.name \
    --cc=kvm@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maxime.coquelin@redhat.com \
    --cc=mcfadden8@llnl.gov \
    --cc=mcgrof@kernel.org \
    --cc=mgorman@suse.de \
    --cc=mike.kravetz@oracle.com \
    --cc=pbonzini@redhat.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=xemul@virtuozzo.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).