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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3281FC433F5 for ; Mon, 15 Nov 2021 15:15:06 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 17D7561AA2 for ; Mon, 15 Nov 2021 15:15:06 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236545AbhKOPR5 (ORCPT ); Mon, 15 Nov 2021 10:17:57 -0500 Received: from foss.arm.com ([217.140.110.172]:56492 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232398AbhKOPRt (ORCPT ); Mon, 15 Nov 2021 10:17:49 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AD01E6D; Mon, 15 Nov 2021 07:14:53 -0800 (PST) Received: from [10.57.82.45] (unknown [10.57.82.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E86B3F766; Mon, 15 Nov 2021 07:14:51 -0800 (PST) Message-ID: <495c65e4-bd97-5f29-d39b-43671acfec78@arm.com> Date: Mon, 15 Nov 2021 15:14:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH 03/11] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Content-Language: en-GB To: Jason Gunthorpe , Christoph Hellwig Cc: Kevin Tian , Chaitanya Kulkarni , Ashok Raj , kvm@vger.kernel.org, rafael@kernel.org, Greg Kroah-Hartman , Cornelia Huck , Will Deacon , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Alex Williamson , Jacob jun Pan , linux-pci@vger.kernel.org, Bjorn Helgaas , Diana Craciun References: <20211115020552.2378167-1-baolu.lu@linux.intel.com> <20211115020552.2378167-4-baolu.lu@linux.intel.com> <20211115133107.GB2379906@nvidia.com> From: Robin Murphy In-Reply-To: <20211115133107.GB2379906@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2021-11-15 13:31, Jason Gunthorpe via iommu wrote: > On Mon, Nov 15, 2021 at 05:21:26AM -0800, Christoph Hellwig wrote: >> On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote: >>> pci_stub allows the admin to block driver binding on a device and make >>> it permanently shared with userspace. Since pci_stub does not do DMA, >>> it is safe. >> >> If an IOMMU is setup and dma-iommu or friends are not used nothing is >> unsafe anyway, it just is that IOMMU won't work.. >> >>> However the admin must understand that using pci_stub allows >>> userspace to attack whatever device it was bound to. >> >> I don't understand this sentence at all. > > If userspace has control of device A and can cause A to issue DMA to > arbitary DMA addresses then there are certain PCI topologies where A > can now issue peer to peer DMA and manipulate the MMMIO registers in > device B. > > A kernel driver on device B is thus subjected to concurrent > manipulation of the device registers from userspace. > > So, a 'safe' kernel driver is one that can tolerate this, and an > 'unsafe' driver is one where userspace can break kernel integrity. You mean in the case where the kernel driver is trying to use device B in a purely PIO mode, such that userspace might potentially be able to interfere with data being transferred in and out of the kernel? Perhaps it's not so clear to put that under a notion of "DMA ownership", since device B's DMA is irrelevant and it's really much more equivalent to /dev/mem access or mmaping BARs to userspace while a driver is bound. > The second issue is DMA - because there is only one iommu_domain > underlying many devices if we give that iommu_domain to userspace it > means the kernel DMA API on other devices no longer works. Actually, the DMA API itself via iommu-dma will "work" just fine in the sense that it will still successfully perform all its operations in the unattached default domain, it's just that if the driver then programs the device to access the returned DMA address, the device is likely to get a nasty surprise. > So no kernel driver doing DMA can work at all, under any PCI topology, > if userspace owns the IO page table. This isn't really about userspace at all - it's true of any case where a kernel driver wants to attach a grouped device to its own unmanaged domain. The fact that the VFIO kernel driver uses its unmanaged domains to map user pages upon user requests is merely a VFIO detail, and VFIO happens to be the only common case where unmanaged domains and non-singleton groups intersect. I'd say that, logically, if you want to put policy on mutual driver/usage compatibility anywhere it should be in iommu_attach_group(). Robin. 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 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6D340C433FE for ; Mon, 15 Nov 2021 15:14:59 +0000 (UTC) Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0CC8963222 for ; Mon, 15 Nov 2021 15:14:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0CC8963222 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.linux-foundation.org Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id C994C4022E; Mon, 15 Nov 2021 15:14:58 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IyZHUdt9Oko; Mon, 15 Nov 2021 15:14:58 +0000 (UTC) Received: from lists.linuxfoundation.org (lf-lists.osuosl.org [IPv6:2605:bc80:3010:104::8cd3:938]) by smtp4.osuosl.org (Postfix) with ESMTPS id A045040218; Mon, 15 Nov 2021 15:14:57 +0000 (UTC) Received: from lf-lists.osuosl.org (localhost [127.0.0.1]) by lists.linuxfoundation.org (Postfix) with ESMTP id 67849C002E; Mon, 15 Nov 2021 15:14:57 +0000 (UTC) Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 23A5FC0012 for ; Mon, 15 Nov 2021 15:14:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 10D4040178 for ; Mon, 15 Nov 2021 15:14:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbhXB6-PX1ty for ; Mon, 15 Nov 2021 15:14:54 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp2.osuosl.org (Postfix) with ESMTP id 9330F40106 for ; Mon, 15 Nov 2021 15:14:54 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id AD01E6D; Mon, 15 Nov 2021 07:14:53 -0800 (PST) Received: from [10.57.82.45] (unknown [10.57.82.45]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3E86B3F766; Mon, 15 Nov 2021 07:14:51 -0800 (PST) Message-ID: <495c65e4-bd97-5f29-d39b-43671acfec78@arm.com> Date: Mon, 15 Nov 2021 15:14:49 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH 03/11] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Content-Language: en-GB To: Jason Gunthorpe , Christoph Hellwig References: <20211115020552.2378167-1-baolu.lu@linux.intel.com> <20211115020552.2378167-4-baolu.lu@linux.intel.com> <20211115133107.GB2379906@nvidia.com> From: Robin Murphy In-Reply-To: <20211115133107.GB2379906@nvidia.com> Cc: Alex Williamson , Kevin Tian , Chaitanya Kulkarni , Ashok Raj , kvm@vger.kernel.org, rafael@kernel.org, Greg Kroah-Hartman , Cornelia Huck , linux-kernel@vger.kernel.org, iommu@lists.linux-foundation.org, Jacob jun Pan , linux-pci@vger.kernel.org, Bjorn Helgaas , Will Deacon , Diana Craciun X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: iommu-bounces@lists.linux-foundation.org Sender: "iommu" On 2021-11-15 13:31, Jason Gunthorpe via iommu wrote: > On Mon, Nov 15, 2021 at 05:21:26AM -0800, Christoph Hellwig wrote: >> On Mon, Nov 15, 2021 at 10:05:44AM +0800, Lu Baolu wrote: >>> pci_stub allows the admin to block driver binding on a device and make >>> it permanently shared with userspace. Since pci_stub does not do DMA, >>> it is safe. >> >> If an IOMMU is setup and dma-iommu or friends are not used nothing is >> unsafe anyway, it just is that IOMMU won't work.. >> >>> However the admin must understand that using pci_stub allows >>> userspace to attack whatever device it was bound to. >> >> I don't understand this sentence at all. > > If userspace has control of device A and can cause A to issue DMA to > arbitary DMA addresses then there are certain PCI topologies where A > can now issue peer to peer DMA and manipulate the MMMIO registers in > device B. > > A kernel driver on device B is thus subjected to concurrent > manipulation of the device registers from userspace. > > So, a 'safe' kernel driver is one that can tolerate this, and an > 'unsafe' driver is one where userspace can break kernel integrity. You mean in the case where the kernel driver is trying to use device B in a purely PIO mode, such that userspace might potentially be able to interfere with data being transferred in and out of the kernel? Perhaps it's not so clear to put that under a notion of "DMA ownership", since device B's DMA is irrelevant and it's really much more equivalent to /dev/mem access or mmaping BARs to userspace while a driver is bound. > The second issue is DMA - because there is only one iommu_domain > underlying many devices if we give that iommu_domain to userspace it > means the kernel DMA API on other devices no longer works. Actually, the DMA API itself via iommu-dma will "work" just fine in the sense that it will still successfully perform all its operations in the unattached default domain, it's just that if the driver then programs the device to access the returned DMA address, the device is likely to get a nasty surprise. > So no kernel driver doing DMA can work at all, under any PCI topology, > if userspace owns the IO page table. This isn't really about userspace at all - it's true of any case where a kernel driver wants to attach a grouped device to its own unmanaged domain. The fact that the VFIO kernel driver uses its unmanaged domains to map user pages upon user requests is merely a VFIO detail, and VFIO happens to be the only common case where unmanaged domains and non-singleton groups intersect. I'd say that, logically, if you want to put policy on mutual driver/usage compatibility anywhere it should be in iommu_attach_group(). Robin. _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu