From: Lu Baolu <baolu.lu@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Kevin Tian <kevin.tian@intel.com>,
Chaitanya Kulkarni <kch@nvidia.com>,
Ashok Raj <ashok.raj@intel.com>,
kvm@vger.kernel.org, rafael@kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Cornelia Huck <cohuck@redhat.com>,
linux-pci@vger.kernel.org, iommu@lists.linux-foundation.org,
linux-kernel@vger.kernel.org,
Alex Williamson <alex.williamson@redhat.com>,
Jacob jun Pan <jacob.jun.pan@intel.com>,
Jason Gunthorpe <jgg@nvidia.com>,
Diana Craciun <diana.craciun@oss.nxp.com>,
Bjorn Helgaas <bhelgaas@google.com>,
Will Deacon <will@kernel.org>
Subject: Re: [PATCH 03/11] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming
Date: Tue, 16 Nov 2021 14:05:27 +0800 [thread overview]
Message-ID: <c7add816-853a-c31d-6425-464512a2de61@linux.intel.com> (raw)
In-Reply-To: <20211115221747.GA1587608@bhelgaas>
Hi Bjorn,
On 11/16/21 6:17 AM, Bjorn Helgaas 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. However the admin must understand that using pci_stub allows
>> userspace to attack whatever device it was bound to.
> This commit log doesn't say what the patch does. I think it tells us
> something about what pci-stub*already* does ("allows admin to block
> driver binding") and something about why that is safe ("does not do
> DMA").
Yes, you are right. This patch is to keep the pci_stub's existing use
case ("allows admin to block driver binding") after moving the viable
check from the vfio to iommu layer (done by this series).
About "safe" (should not be part of this description), there are two
sides from my understanding:
#1) The pci_stub driver itself doesn't control the device to do any DMA.
So it won't interfere the user space through device DMA.
#2) The pci_stub driver doesn't access the PCI bar and doesn't build any
device driver state around any value in the bar. So other devices
in the same iommu group (assigned to user space) have no means to
change the kernel driver consistency via p2p access.
>
> But it doesn't say what this patch changes. Based on the subject
> line, I expected something like:
>
> As of ("<commit subject>"), <some function>() marks the iommu_group
> as containing only devices with kernel drivers that manage DMA.
>
> Avoid this default behavior for pci-stub because it does not program
> any DMA itself. This allows <some desirable behavior>.
>
Sure. I will rephrase the description like above.
Best regards,
baolu
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
next prev parent reply other threads:[~2021-11-16 6:05 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-15 2:05 [PATCH 00/11] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu
2021-11-15 2:05 ` [PATCH 01/11] iommu: Add device dma ownership set/release interfaces Lu Baolu
2021-11-15 13:14 ` Christoph Hellwig
2021-11-16 1:57 ` Lu Baolu
2021-11-16 13:46 ` Jason Gunthorpe via iommu
2021-11-17 5:22 ` Lu Baolu
2021-11-17 13:35 ` Jason Gunthorpe via iommu
2021-11-18 1:12 ` Lu Baolu
2021-11-18 14:10 ` Jason Gunthorpe via iommu
2021-11-18 2:39 ` Tian, Kevin
2021-11-18 13:33 ` Jason Gunthorpe via iommu
2021-11-19 5:44 ` Tian, Kevin
2021-11-19 11:14 ` Lu Baolu
2021-11-19 15:06 ` Jörg Rödel
2021-11-19 15:43 ` Jason Gunthorpe via iommu
2021-11-20 11:16 ` Lu Baolu
2021-11-19 12:56 ` Jason Gunthorpe via iommu
2021-11-15 20:38 ` Bjorn Helgaas
2021-11-16 1:52 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 02/11] driver core: Set DMA ownership during driver bind/unbind Lu Baolu
2021-11-15 6:59 ` Greg Kroah-Hartman
2021-11-15 13:20 ` Christoph Hellwig
2021-11-15 13:38 ` Jason Gunthorpe via iommu
2021-11-15 13:19 ` Christoph Hellwig
2021-11-15 13:24 ` Jason Gunthorpe via iommu
2021-11-15 15:37 ` Robin Murphy
2021-11-15 15:56 ` Jason Gunthorpe via iommu
2021-11-15 18:15 ` Christoph Hellwig
2021-11-15 18:35 ` Robin Murphy
2021-11-15 19:39 ` Jason Gunthorpe via iommu
2021-11-15 2:05 ` [PATCH 03/11] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Lu Baolu
2021-11-15 13:21 ` Christoph Hellwig
2021-11-15 13:31 ` Jason Gunthorpe via iommu
2021-11-15 15:14 ` Robin Murphy
2021-11-15 16:17 ` Jason Gunthorpe via iommu
2021-11-15 17:54 ` Robin Murphy
2021-11-15 18:19 ` Christoph Hellwig
2021-11-15 18:44 ` Robin Murphy
2021-11-15 19:22 ` Jason Gunthorpe via iommu
2021-11-15 20:58 ` Robin Murphy
2021-11-15 21:19 ` Jason Gunthorpe via iommu
2021-11-15 20:48 ` Bjorn Helgaas
2021-11-15 22:17 ` Bjorn Helgaas
2021-11-16 6:05 ` Lu Baolu [this message]
2021-11-15 2:05 ` [PATCH 04/11] PCI: portdrv: " Lu Baolu
2021-11-15 20:44 ` Bjorn Helgaas
2021-11-16 7:24 ` Lu Baolu
2021-11-16 20:22 ` Bjorn Helgaas
2021-11-16 20:48 ` Jason Gunthorpe via iommu
2021-11-15 2:05 ` [PATCH 05/11] iommu: Add security context management for assigned devices Lu Baolu
2021-11-15 13:22 ` Christoph Hellwig
2021-11-16 7:25 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 06/11] iommu: Expose group variants of dma ownership interfaces Lu Baolu
2021-11-15 13:27 ` Christoph Hellwig
2021-11-16 9:42 ` Lu Baolu
2021-11-15 2:05 ` [PATCH 07/11] vfio: Use DMA_OWNER_USER to declaim passthrough devices Lu Baolu
2021-11-15 2:05 ` [PATCH 08/11] vfio: Remove use of vfio_group_viable() Lu Baolu
2021-11-15 2:05 ` [PATCH 09/11] vfio: Delete the unbound_list Lu Baolu
2021-11-15 2:05 ` [PATCH 10/11] vfio: Remove iommu group notifier Lu Baolu
2021-11-15 2:05 ` [PATCH 11/11] iommu: Remove iommu group changes notifier Lu Baolu
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=c7add816-853a-c31d-6425-464512a2de61@linux.intel.com \
--to=baolu.lu@linux.intel.com \
--cc=alex.williamson@redhat.com \
--cc=ashok.raj@intel.com \
--cc=bhelgaas@google.com \
--cc=cohuck@redhat.com \
--cc=diana.craciun@oss.nxp.com \
--cc=gregkh@linuxfoundation.org \
--cc=helgaas@kernel.org \
--cc=iommu@lists.linux-foundation.org \
--cc=jacob.jun.pan@intel.com \
--cc=jgg@nvidia.com \
--cc=kch@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=will@kernel.org \
/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