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 X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6BC1CC43381 for ; Tue, 12 Mar 2019 20:00:11 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2BF5020449 for ; Tue, 12 Mar 2019 20:00:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=oracle.com header.i=@oracle.com header.b="HNfNGy6M" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727186AbfCLUAK (ORCPT ); Tue, 12 Mar 2019 16:00:10 -0400 Received: from aserp2130.oracle.com ([141.146.126.79]:56372 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726329AbfCLUAJ (ORCPT ); Tue, 12 Mar 2019 16:00:09 -0400 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x2CJx5MX109207; Tue, 12 Mar 2019 19:59:49 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=A9gtozJFv5iJI4Lopf5E2MEM4Cit9pl4LJXAm7hrIaU=; b=HNfNGy6MLKML/gftAsYYxKcbb5V2y/J95OrbzuvtCMlRlroDupWboAUPv6W2O30oYMH3 ncwOenKTSc0IrwSt9A3qYnSVWRluJGESnk5sjN3vjVW7aTSPQmdNXjpWt4YEnnrtKoa6 JF6gUNTa/wls2MtPfUvnrqu+savyt/Nfvo/vc6kqFyds8BSDgVl9zn0/mJCChlEAyhgu FB+t84+PjLGD/M4P79fuI+t4fXhgUFvRtz6t0p0Dp5gainpkfW40/LpfYsLm31TtG1t9 XPwJNkEEqvHugD4944rzrqiwu92EygE1hbnPSr+3JJKwjEQOZQ1v5PBAyGlH05P+kvhd ag== Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2r430eqf9m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 19:59:49 +0000 Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id x2CJxhY9015680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 12 Mar 2019 19:59:43 GMT Received: from abhmp0004.oracle.com (abhmp0004.oracle.com [141.146.116.10]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x2CJxbr9011784; Tue, 12 Mar 2019 19:59:37 GMT Received: from [192.168.1.222] (/50.38.38.67) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 12 Mar 2019 12:59:36 -0700 Subject: Re: [PATCH 0/3] userfaultfd: allow to forbid unprivileged users To: Peter Xu , linux-kernel@vger.kernel.org Cc: Paolo Bonzini , Hugh Dickins , Luis Chamberlain , Maxime Coquelin , kvm@vger.kernel.org, Jerome Glisse , Pavel Emelyanov , Johannes Weiner , Martin Cracauer , Denis Plotnikov , linux-mm@kvack.org, Marty McFadden , Maya Gokhale , Andrea Arcangeli , Mike Rapoport , Kees Cook , Mel Gorman , "Kirill A . Shutemov" , linux-fsdevel@vger.kernel.org, "Dr . David Alan Gilbert" , Andrew Morton References: <20190311093701.15734-1-peterx@redhat.com> From: Mike Kravetz Message-ID: <58e63635-fc1b-cb53-a4d1-237e6b8b7236@oracle.com> Date: Tue, 12 Mar 2019 12:59:34 -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: <20190311093701.15734-1-peterx@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9193 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=681 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903120135 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. 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. -- Mike Kravetz From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Kravetz Subject: Re: [PATCH 0/3] userfaultfd: allow to forbid unprivileged users Date: Tue, 12 Mar 2019 12:59:34 -0700 Message-ID: <58e63635-fc1b-cb53-a4d1-237e6b8b7236@oracle.com> References: <20190311093701.15734-1-peterx@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: Paolo Bonzini , Hugh Dickins , Luis Chamberlain , Maxime Coquelin , kvm@vger.kernel.org, Jerome Glisse , Pavel Emelyanov , Johannes Weiner , Martin Cracauer , Denis Plotnikov , linux-mm@kvack.org, Marty McFadden , Maya Gokhale , Andrea Arcangeli , Mike Rapoport , Kees Cook , Mel Gorman , "Kirill A . Shutemov" , linux-fsdevel@vger.kernel.org, "Dr . David Alan Gilbert" , Andrew Morton , linux-kernel@vger.kernel.org Return-path: In-Reply-To: <20190311093701.15734-1-peterx@redhat.com> Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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. 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. -- Mike Kravetz