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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED 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 D6736C43382 for ; Thu, 27 Sep 2018 15:06:28 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 96A23216C4 for ; Thu, 27 Sep 2018 15:06:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 96A23216C4 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-pci-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727534AbeI0VZI (ORCPT ); Thu, 27 Sep 2018 17:25:08 -0400 Received: from foss.arm.com ([217.140.101.70]:36018 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727212AbeI0VZI (ORCPT ); Thu, 27 Sep 2018 17:25:08 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C56F27A9; Thu, 27 Sep 2018 08:06:26 -0700 (PDT) Received: from [10.4.12.111] (ostrya.Emea.Arm.com [10.4.12.111]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 17A0A3F5BD; Thu, 27 Sep 2018 08:06:22 -0700 (PDT) Subject: Re: [PATCH v3 02/10] iommu/sva: Bind process address spaces to devices To: Jacob Pan Cc: Lu Baolu , "iommu@lists.linux-foundation.org" , "joro@8bytes.org" , "linux-pci@vger.kernel.org" , "jcrouse@codeaurora.org" , "alex.williamson@redhat.com" , "Jonathan.Cameron@huawei.com" , "christian.koenig@amd.com" , "eric.auger@redhat.com" , "kevin.tian@intel.com" , "yi.l.liu@intel.com" , Andrew Murray , Will Deacon , Robin Murphy , "ashok.raj@intel.com" , "xuzaibo@huawei.com" , "liguozhu@hisilicon.com" , "okaya@codeaurora.org" , "bharatku@xilinx.com" , "ilias.apalodimas@linaro.org" , "shunyong.yang@hxt-semitech.com" References: <20180920170046.20154-1-jean-philippe.brucker@arm.com> <20180920170046.20154-3-jean-philippe.brucker@arm.com> <7cbd503a-c79e-3c40-7388-ce6c23f7f536@arm.com> <20180926110103.45b57f75@jacob-builder> From: Jean-Philippe Brucker Message-ID: <79c0e0e1-691e-b8e1-0e68-21876135d2ab@arm.com> Date: Thu, 27 Sep 2018 16:06:06 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <20180926110103.45b57f75@jacob-builder> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On 26/09/2018 19:01, Jacob Pan wrote: > On Mon, 24 Sep 2018 13:07:47 +0100 > Jean-Philippe Brucker wrote: > >> On 23/09/2018 04:05, Lu Baolu wrote: >> > Hi, >> > >> > On 09/21/2018 01:00 AM, Jean-Philippe Brucker wrote:  >> >> Add bind() and unbind() operations to the IOMMU API. Bind() >> >> returns a PASID that drivers can program in hardware, to let their >> >> devices access an mm. This patch only adds skeletons for the >> >> device driver API, most of the implementation is still missing.  >> > >> > Is it possible that a malicious process can unbind a pasid which is >> > used by another normal process?  >> >> Yes, it's up to the device driver that calls unbind() to check that >> the caller is allowed to unbind this PASID. We can't do it ourselves >> since unbind() could also be called from a kernel thread for example >> from a cleanup function in some workqueue, outside the context of the >> process to unbind. Actually I'm not too concerned about a process unbinding another one, since in general only the kernel will hold the PASID values. Userspace shouldn't even need to see them, so issuing unbind() with the wrong PASID isn't an easy mistake. > I am wondering if we can avoid the complexity around permission > checking by simply _only_ allow bind/unbind() on current mm? what would > be the missing use cases if we bind current only? > It can also avoid other race such as unbind and mmu_notifier release > call. That's tempting but may be too restrictive. I just tried to copy what the current AMD and Intel drivers do in their SVA implementation, but I don't know if users will need all of it. At the moment the amdkfd driver does unbind() from a workqueue, although moving to the generic API might simplify things there. Callers can easily enforce that only current->mm is passed to bind(). I don't know if allowing a process to bind another one is a real use-case, but the permission check on the device driver side is fairly easy, and disallowing it wouldn't simplify iommu-sva. Even if we allow bind() only on current, forcing unbind() to be done on current means that the driver can't clean things up from a workqueue. But you're right that this restriction would make things *much* simpler for the exit()/unbind() race. Thanks, Jean From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Philippe Brucker Subject: Re: [PATCH v3 02/10] iommu/sva: Bind process address spaces to devices Date: Thu, 27 Sep 2018 16:06:06 +0100 Message-ID: <79c0e0e1-691e-b8e1-0e68-21876135d2ab@arm.com> References: <20180920170046.20154-1-jean-philippe.brucker@arm.com> <20180920170046.20154-3-jean-philippe.brucker@arm.com> <7cbd503a-c79e-3c40-7388-ce6c23f7f536@arm.com> <20180926110103.45b57f75@jacob-builder> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Return-path: In-Reply-To: <20180926110103.45b57f75@jacob-builder> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Jacob Pan Cc: "kevin.tian-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org" , "linux-pci-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "ilias.apalodimas-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org" , Will Deacon , "iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org" , "okaya-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org" , "alex.williamson-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "liguozhu-C8/M+/jPZTeaMJb+Lgu22Q@public.gmane.org" , Robin Murphy , "christian.koenig-5C7GfCeVMHo@public.gmane.org" List-Id: iommu@lists.linux-foundation.org T24gMjYvMDkvMjAxOCAxOTowMSwgSmFjb2IgUGFuIHdyb3RlOgo+IE9uIE1vbiwgMjQgU2VwIDIw MTggMTM6MDc6NDcgKzAxMDAKPiBKZWFuLVBoaWxpcHBlIEJydWNrZXIgPGplYW4tcGhpbGlwcGUu YnJ1Y2tlckBhcm0uY29tPiB3cm90ZToKPiAKPj4gT24gMjMvMDkvMjAxOCAwNDowNSwgTHUgQmFv bHUgd3JvdGU6Cj4+ID4gSGksCj4+ID4gCj4+ID4gT24gMDkvMjEvMjAxOCAwMTowMCBBTSwgSmVh bi1QaGlsaXBwZSBCcnVja2VyIHdyb3RlOsKgIAo+PiA+PiBBZGQgYmluZCgpIGFuZCB1bmJpbmQo KSBvcGVyYXRpb25zIHRvIHRoZSBJT01NVSBBUEkuIEJpbmQoKQo+PiA+PiByZXR1cm5zIGEgUEFT SUQgdGhhdCBkcml2ZXJzIGNhbiBwcm9ncmFtIGluIGhhcmR3YXJlLCB0byBsZXQgdGhlaXIKPj4g Pj4gZGV2aWNlcyBhY2Nlc3MgYW4gbW0uIFRoaXMgcGF0Y2ggb25seSBhZGRzIHNrZWxldG9ucyBm b3IgdGhlCj4+ID4+IGRldmljZSBkcml2ZXIgQVBJLCBtb3N0IG9mIHRoZSBpbXBsZW1lbnRhdGlv biBpcyBzdGlsbCBtaXNzaW5nLsKgIAo+PiA+IAo+PiA+IElzIGl0IHBvc3NpYmxlIHRoYXQgYSBt YWxpY2lvdXMgcHJvY2VzcyBjYW4gdW5iaW5kIGEgcGFzaWQgd2hpY2ggaXMKPj4gPiB1c2VkIGJ5 IGFub3RoZXIgbm9ybWFsIHByb2Nlc3M/wqAgCj4+IAo+PiBZZXMsIGl0J3MgdXAgdG8gdGhlIGRl dmljZSBkcml2ZXIgdGhhdCBjYWxscyB1bmJpbmQoKSB0byBjaGVjayB0aGF0Cj4+IHRoZSBjYWxs ZXIgaXMgYWxsb3dlZCB0byB1bmJpbmQgdGhpcyBQQVNJRC4gV2UgY2FuJ3QgZG8gaXQgb3Vyc2Vs dmVzCj4+IHNpbmNlIHVuYmluZCgpIGNvdWxkIGFsc28gYmUgY2FsbGVkIGZyb20gYSBrZXJuZWwg dGhyZWFkIGZvciBleGFtcGxlCj4+IGZyb20gYSBjbGVhbnVwIGZ1bmN0aW9uIGluIHNvbWUgd29y a3F1ZXVlLCBvdXRzaWRlIHRoZSBjb250ZXh0IG9mIHRoZQo+PiBwcm9jZXNzIHRvIHVuYmluZC4K CkFjdHVhbGx5IEknbSBub3QgdG9vIGNvbmNlcm5lZCBhYm91dCBhIHByb2Nlc3MgdW5iaW5kaW5n IGFub3RoZXIgb25lLApzaW5jZSBpbiBnZW5lcmFsIG9ubHkgdGhlIGtlcm5lbCB3aWxsIGhvbGQg dGhlIFBBU0lEIHZhbHVlcy4gVXNlcnNwYWNlCnNob3VsZG4ndCBldmVuIG5lZWQgdG8gc2VlIHRo ZW0sIHNvIGlzc3VpbmcgdW5iaW5kKCkgd2l0aCB0aGUgd3JvbmcKUEFTSUQgaXNuJ3QgYW4gZWFz eSBtaXN0YWtlLgoKPiBJIGFtIHdvbmRlcmluZyBpZiB3ZSBjYW4gYXZvaWQgdGhlIGNvbXBsZXhp dHkgYXJvdW5kIHBlcm1pc3Npb24KPiBjaGVja2luZyBieSBzaW1wbHkgX29ubHlfIGFsbG93IGJp bmQvdW5iaW5kKCkgb24gY3VycmVudCBtbT8gd2hhdCB3b3VsZAo+IGJlIHRoZSBtaXNzaW5nIHVz ZSBjYXNlcyBpZiB3ZSBiaW5kIGN1cnJlbnQgb25seT8KPiBJdCBjYW4gYWxzbyBhdm9pZCBvdGhl ciByYWNlIHN1Y2ggYXMgdW5iaW5kIGFuZCBtbXVfbm90aWZpZXIgcmVsZWFzZQo+IGNhbGwuCgpU aGF0J3MgdGVtcHRpbmcgYnV0IG1heSBiZSB0b28gcmVzdHJpY3RpdmUuIEkganVzdCB0cmllZCB0 byBjb3B5IHdoYXQKdGhlIGN1cnJlbnQgQU1EIGFuZCBJbnRlbCBkcml2ZXJzIGRvIGluIHRoZWly IFNWQSBpbXBsZW1lbnRhdGlvbiwgYnV0IEkKZG9uJ3Qga25vdyBpZiB1c2VycyB3aWxsIG5lZWQg YWxsIG9mIGl0LiBBdCB0aGUgbW9tZW50IHRoZSBhbWRrZmQgZHJpdmVyCmRvZXMgdW5iaW5kKCkg ZnJvbSBhIHdvcmtxdWV1ZSwgYWx0aG91Z2ggbW92aW5nIHRvIHRoZSBnZW5lcmljIEFQSSBtaWdo dApzaW1wbGlmeSB0aGluZ3MgdGhlcmUuCgpDYWxsZXJzIGNhbiBlYXNpbHkgZW5mb3JjZSB0aGF0 IG9ubHkgY3VycmVudC0+bW0gaXMgcGFzc2VkIHRvIGJpbmQoKS4gSQpkb24ndCBrbm93IGlmIGFs bG93aW5nIGEgcHJvY2VzcyB0byBiaW5kIGFub3RoZXIgb25lIGlzIGEgcmVhbCB1c2UtY2FzZSwK YnV0IHRoZSBwZXJtaXNzaW9uIGNoZWNrIG9uIHRoZSBkZXZpY2UgZHJpdmVyIHNpZGUgaXMgZmFp cmx5IGVhc3ksIGFuZApkaXNhbGxvd2luZyBpdCB3b3VsZG4ndCBzaW1wbGlmeSBpb21tdS1zdmEu CgpFdmVuIGlmIHdlIGFsbG93IGJpbmQoKSBvbmx5IG9uIGN1cnJlbnQsIGZvcmNpbmcgdW5iaW5k KCkgdG8gYmUgZG9uZSBvbgpjdXJyZW50IG1lYW5zIHRoYXQgdGhlIGRyaXZlciBjYW4ndCBjbGVh biB0aGluZ3MgdXAgZnJvbSBhIHdvcmtxdWV1ZS4KQnV0IHlvdSdyZSByaWdodCB0aGF0IHRoaXMg cmVzdHJpY3Rpb24gd291bGQgbWFrZSB0aGluZ3MgKm11Y2gqIHNpbXBsZXIKZm9yIHRoZSBleGl0 KCkvdW5iaW5kKCkgcmFjZS4KClRoYW5rcywKSmVhbgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwppb21tdSBtYWlsaW5nIGxpc3QKaW9tbXVAbGlzdHMubGlu dXgtZm91bmRhdGlvbi5vcmcKaHR0cHM6Ly9saXN0cy5saW51eGZvdW5kYXRpb24ub3JnL21haWxt YW4vbGlzdGluZm8vaW9tbXU=