Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [PATCH 0/3] userfaultfd: allow to forbid unprivileged users
To:     Peter Xu <peterx@redhat.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>
References: <20190311093701.15734-1-peterx@redhat.com>
 <58e63635-fc1b-cb53-a4d1-237e6b8b7236@oracle.com>
 <20190313060023.GD2433@xz-x1>
From:   Mike Kravetz <mike.kravetz@oracle.com>
Message-ID: <dd56566e-7b7f-51f6-bf01-ffda530a8073@oracle.com>
Date:   Wed, 13 Mar 2019 10:50:48 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <20190313060023.GD2433@xz-x1>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 3/12/19 11:00 PM, Peter Xu wrote:
> 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?

Wow!  I did not realize that apps which specify mmap(MAP_HUGETLB) do not
need any special privilege to use huge pages.  Honestly, I am not sure if
that was by design or a bug.  The memfd_create code is based on the MAP_HUGETLB
code and also does not need any special privilege.  Not to sidetrack this
discussion, but people on Cc may know if this is a bug or by design.  My
opinion is that huge pages are a limited resource and should be under control.
One needs to be a member of a special group (or root) to access via System V
interfaces.

The DB use case only does mmap of files in an explicitly mounted filesystem.
So, limiting it in that manner would work for them.

> 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?

I need to confirm with the DB people, but it is my understanding that the
exact process which does the open/mmap will be the one using userfaultfd.
-- 
Mike Kravetz