All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@nvidia.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Lu Baolu <baolu.lu@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Joerg Roedel <joro@8bytes.org>,
	Alex Williamson <alex.williamson@redhat.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Kevin Tian <kevin.tian@intel.com>,
	Ashok Raj <ashok.raj@intel.com>, Will Deacon <will@kernel.org>,
	Robin Murphy <robin.murphy@arm.com>,
	Dan Williams <dan.j.williams@intel.com>,
	rafael@kernel.org, Diana Craciun <diana.craciun@oss.nxp.com>,
	Cornelia Huck <cohuck@redhat.com>,
	Eric Auger <eric.auger@redhat.com>, Liu Yi L <yi.l.liu@intel.com>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Stuart Yoder <stuyoder@gmail.com>,
	Laurentiu Tudor <laurentiu.tudor@nxp.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	David Airlie <airlied@linux.ie>, Daniel Vetter <daniel@ffwll.ch>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Li Yang <leoyang.li@nxp.com>, Dmitry Osipenko <digetx@gmail.com>,
	iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 01/14] iommu: Add dma ownership management interfaces
Date: Tue, 4 Jan 2022 15:23:48 -0400	[thread overview]
Message-ID: <20220104192348.GK2328285@nvidia.com> (raw)
In-Reply-To: <20220104164100.GA101735@bhelgaas>

On Tue, Jan 04, 2022 at 10:41:00AM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 04, 2022 at 02:08:00AM -0800, Christoph Hellwig wrote:
> > On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote:
> > > Multiple devices may be placed in the same IOMMU group because they
> > > cannot be isolated from each other. These devices must either be
> > > entirely under kernel control or userspace control, never a mixture.
> 
> I guess the reason is that if a group contained a mixture, userspace
> could attack the kernel by programming a device to DMA to a device
> owned by the kernel?

There are several of reasons, including what you guess, but for the
design of the series now we can just focus on the group's domain.

If the kernel is using a device then the kernel driver uses the DMA
API and the group's domain must always point to the default domain so
long as a DMA API user exists. Hopefully it is clear to understand

> > > The device driver oriented interfaces are,
> > > 
> > > 	int iommu_device_use_dma_api(struct device *dev);
> > > 	void iommu_device_unuse_dma_api(struct device *dev);
> 
> Nit, do we care whether it uses the actual DMA API?  Or is it just
> that iommu_device_use_dma_api() tells us the driver may program the
> device to do DMA?

As the main purpose, yes this is all about the DMA API because it
asserts the group domain is the DMA API's domain.

There is a secondary purpose that has to do with the user/kernel
attack you mentioned above. Maintaining the DMA API domain also
prevents VFIO from allowing userspace to operate any device in the
group which blocks P2P attacks to MMIO of other devices.

This is why, even if the driver doesn't use DMA, it should still do a
iommu_device_use_dma_api(), except in the special cases where we don't
care about P2P attacks (eg pci-stub, bridges, etc).

> > > The vfio oriented interfaces are,
> > > 
> > > 	int iommu_group_set_dma_owner(struct iommu_group *group,
> > > 				      void *owner);
> > > 	void iommu_group_release_dma_owner(struct iommu_group *group);
> > > 	bool iommu_group_dma_owner_claimed(struct iommu_group *group);
> > > 
> > > The device userspace assignment must be disallowed if the set dma owner
> > > interface returns failure.
> 
> Can you connect this back to the "never a mixture" from the beginning?
> If all you cared about was prevent an IOMMU group from containing
> devices with a mixture of kernel drivers and userspace drivers, I
> assume you could do that without iommu_device_use_dma_api().  So is
> this a way to *allow* a mixture under certain restricted conditions?

It is not about user/kernel, it is about arbitrating the shared
group->domain against multiple different requests to set it to
something else.

Lu, Given that the word 'user' was deleted from the API entirely it
makes sense to reword these commit messages to focus less on user vs
kernel and more on ownership of the domain pointer.

Jason

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: Stuart Yoder <stuyoder@gmail.com>,
	rafael@kernel.org, David Airlie <airlied@linux.ie>,
	linux-pci@vger.kernel.org,
	Thierry Reding <thierry.reding@gmail.com>,
	Diana Craciun <diana.craciun@oss.nxp.com>,
	Dmitry Osipenko <digetx@gmail.com>, Will Deacon <will@kernel.org>,
	Ashok Raj <ashok.raj@intel.com>,
	Jonathan Hunter <jonathanh@nvidia.com>,
	Christoph Hellwig <hch@infradead.org>,
	Kevin Tian <kevin.tian@intel.com>,
	Chaitanya Kulkarni <kch@nvidia.com>,
	Alex Williamson <alex.williamson@redhat.com>,
	kvm@vger.kernel.org, Bjorn Helgaas <bhelgaas@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Cornelia Huck <cohuck@redhat.com>,
	linux-kernel@vger.kernel.org, Li Yang <leoyang.li@nxp.com>,
	iommu@lists.linux-foundation.org,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Daniel Vetter <daniel@ffwll.ch>,
	Robin Murphy <robin.murphy@arm.com>
Subject: Re: [PATCH v5 01/14] iommu: Add dma ownership management interfaces
Date: Tue, 4 Jan 2022 15:23:48 -0400	[thread overview]
Message-ID: <20220104192348.GK2328285@nvidia.com> (raw)
In-Reply-To: <20220104164100.GA101735@bhelgaas>

On Tue, Jan 04, 2022 at 10:41:00AM -0600, Bjorn Helgaas wrote:
> On Tue, Jan 04, 2022 at 02:08:00AM -0800, Christoph Hellwig wrote:
> > On Tue, Jan 04, 2022 at 09:56:31AM +0800, Lu Baolu wrote:
> > > Multiple devices may be placed in the same IOMMU group because they
> > > cannot be isolated from each other. These devices must either be
> > > entirely under kernel control or userspace control, never a mixture.
> 
> I guess the reason is that if a group contained a mixture, userspace
> could attack the kernel by programming a device to DMA to a device
> owned by the kernel?

There are several of reasons, including what you guess, but for the
design of the series now we can just focus on the group's domain.

If the kernel is using a device then the kernel driver uses the DMA
API and the group's domain must always point to the default domain so
long as a DMA API user exists. Hopefully it is clear to understand

> > > The device driver oriented interfaces are,
> > > 
> > > 	int iommu_device_use_dma_api(struct device *dev);
> > > 	void iommu_device_unuse_dma_api(struct device *dev);
> 
> Nit, do we care whether it uses the actual DMA API?  Or is it just
> that iommu_device_use_dma_api() tells us the driver may program the
> device to do DMA?

As the main purpose, yes this is all about the DMA API because it
asserts the group domain is the DMA API's domain.

There is a secondary purpose that has to do with the user/kernel
attack you mentioned above. Maintaining the DMA API domain also
prevents VFIO from allowing userspace to operate any device in the
group which blocks P2P attacks to MMIO of other devices.

This is why, even if the driver doesn't use DMA, it should still do a
iommu_device_use_dma_api(), except in the special cases where we don't
care about P2P attacks (eg pci-stub, bridges, etc).

> > > The vfio oriented interfaces are,
> > > 
> > > 	int iommu_group_set_dma_owner(struct iommu_group *group,
> > > 				      void *owner);
> > > 	void iommu_group_release_dma_owner(struct iommu_group *group);
> > > 	bool iommu_group_dma_owner_claimed(struct iommu_group *group);
> > > 
> > > The device userspace assignment must be disallowed if the set dma owner
> > > interface returns failure.
> 
> Can you connect this back to the "never a mixture" from the beginning?
> If all you cared about was prevent an IOMMU group from containing
> devices with a mixture of kernel drivers and userspace drivers, I
> assume you could do that without iommu_device_use_dma_api().  So is
> this a way to *allow* a mixture under certain restricted conditions?

It is not about user/kernel, it is about arbitrating the shared
group->domain against multiple different requests to set it to
something else.

Lu, Given that the word 'user' was deleted from the API entirely it
makes sense to reword these commit messages to focus less on user vs
kernel and more on ownership of the domain pointer.

Jason
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu

  reply	other threads:[~2022-01-04 19:24 UTC|newest]

Thread overview: 112+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04  1:56 [PATCH v5 00/14] Fix BUG_ON in vfio_iommu_group_notifier() Lu Baolu
2022-01-04  1:56 ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 01/14] iommu: Add dma ownership management interfaces Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04 10:08   ` Christoph Hellwig
2022-01-04 10:08     ` Christoph Hellwig
2022-01-04 16:41     ` Bjorn Helgaas
2022-01-04 16:41       ` Bjorn Helgaas
2022-01-04 19:23       ` Jason Gunthorpe [this message]
2022-01-04 19:23         ` Jason Gunthorpe via iommu
2022-01-06  3:18         ` Lu Baolu
2022-01-06  3:18           ` Lu Baolu
2022-01-06  3:54         ` Lu Baolu
2022-01-06  3:54           ` Lu Baolu
2022-01-06 15:46           ` Jason Gunthorpe
2022-01-06 15:46             ` Jason Gunthorpe via iommu
2022-01-07  1:50             ` Lu Baolu
2022-01-07  1:50               ` Lu Baolu
2022-01-06  3:43       ` Lu Baolu
2022-01-06  3:43         ` Lu Baolu
2022-01-06  3:47       ` Lu Baolu
2022-01-06  3:47         ` Lu Baolu
2022-01-06  3:51       ` Lu Baolu
2022-01-06  3:51         ` Lu Baolu
2022-01-05  6:57     ` Lu Baolu
2022-01-05  6:57       ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 02/14] driver core: Add dma_cleanup callback in bus_type Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04 10:08   ` Christoph Hellwig
2022-01-04 10:08     ` Christoph Hellwig
2022-01-04 12:39     ` Jason Gunthorpe
2022-01-04 12:39       ` Jason Gunthorpe via iommu
2022-01-04 13:04       ` Greg Kroah-Hartman
2022-01-04 13:04         ` Greg Kroah-Hartman
2022-02-08  5:55         ` Lu Baolu
2022-02-08  5:55           ` Lu Baolu
2022-02-08 11:35           ` Greg Kroah-Hartman
2022-02-08 11:35             ` Greg Kroah-Hartman
2022-02-14 10:01     ` Greg Kroah-Hartman
2022-02-14 10:01       ` Greg Kroah-Hartman
2022-02-14 10:02   ` Greg Kroah-Hartman
2022-02-14 10:02     ` Greg Kroah-Hartman
2022-01-04  1:56 ` [PATCH v5 03/14] amba: Stop sharing platform_dma_configure() Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 04/14] driver core: platform: Add driver dma ownership management Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-02-14  9:59   ` Greg Kroah-Hartman
2022-02-14  9:59     ` Greg Kroah-Hartman
2022-02-14 13:18     ` Jason Gunthorpe
2022-02-14 13:18       ` Jason Gunthorpe via iommu
2022-02-14 13:37       ` Greg Kroah-Hartman
2022-02-14 13:37         ` Greg Kroah-Hartman
2022-02-14 13:43         ` Jason Gunthorpe
2022-02-14 13:43           ` Jason Gunthorpe via iommu
2022-01-04  1:56 ` [PATCH v5 05/14] amba: " Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 06/14] bus: fsl-mc: " Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 07/14] PCI: " Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-02-14 10:03   ` Greg Kroah-Hartman
2022-02-14 10:03     ` Greg Kroah-Hartman
2022-02-14 12:38     ` Jason Gunthorpe
2022-02-14 12:38       ` Jason Gunthorpe via iommu
2022-02-14 12:51       ` Greg Kroah-Hartman
2022-02-14 12:51         ` Greg Kroah-Hartman
2022-02-14 13:11         ` Jason Gunthorpe
2022-02-14 13:11           ` Jason Gunthorpe via iommu
2022-02-14 13:39           ` Greg Kroah-Hartman
2022-02-14 13:39             ` Greg Kroah-Hartman
2022-02-14 13:43             ` Jason Gunthorpe
2022-02-14 13:43               ` Jason Gunthorpe via iommu
2022-02-15  3:06               ` Lu Baolu
2022-02-15  3:06                 ` Lu Baolu
2022-02-23 18:00   ` Bjorn Helgaas
2022-02-23 18:00     ` Bjorn Helgaas
2022-02-23 18:07     ` Jason Gunthorpe
2022-02-23 18:07       ` Jason Gunthorpe via iommu
2022-01-04  1:56 ` [PATCH v5 08/14] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 09/14] PCI: portdrv: " Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04 17:06   ` Bjorn Helgaas
2022-01-04 17:06     ` Bjorn Helgaas
2022-01-04 19:26     ` Jason Gunthorpe
2022-01-04 19:26       ` Jason Gunthorpe via iommu
2022-01-04 19:51       ` Bjorn Helgaas
2022-01-04 19:51         ` Bjorn Helgaas
2022-01-05  0:35         ` Jason Gunthorpe
2022-01-05  0:35           ` Jason Gunthorpe via iommu
2022-01-06  4:12     ` Lu Baolu
2022-01-06  4:12       ` Lu Baolu
2022-01-06 18:32       ` Bjorn Helgaas
2022-01-06 18:32         ` Bjorn Helgaas
2022-01-07  1:53         ` Lu Baolu
2022-01-07  1:53           ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 10/14] vfio: Set DMA ownership for VFIO devices Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 11/14] vfio: Remove use of vfio_group_viable() Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 12/14] vfio: Delete the unbound_list Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 13/14] vfio: Remove iommu group notifier Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04  1:56 ` [PATCH v5 14/14] iommu: Remove iommu group changes notifier Lu Baolu
2022-01-04  1:56   ` Lu Baolu
2022-01-04 12:48 ` [PATCH v5 00/14] Fix BUG_ON in vfio_iommu_group_notifier() Jason Gunthorpe
2022-01-04 12:48   ` Jason Gunthorpe via iommu
2022-01-05  6:52   ` Lu Baolu
2022-01-05  6:52     ` Lu Baolu
2022-02-18  1:07 ` Lu Baolu
2022-02-18  1:07   ` 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=20220104192348.GK2328285@nvidia.com \
    --to=jgg@nvidia.com \
    --cc=airlied@linux.ie \
    --cc=alex.williamson@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=baolu.lu@linux.intel.com \
    --cc=bhelgaas@google.com \
    --cc=cohuck@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=diana.craciun@oss.nxp.com \
    --cc=digetx@gmail.com \
    --cc=eric.auger@redhat.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=helgaas@kernel.org \
    --cc=iommu@lists.linux-foundation.org \
    --cc=jacob.jun.pan@intel.com \
    --cc=jonathanh@nvidia.com \
    --cc=joro@8bytes.org \
    --cc=kch@nvidia.com \
    --cc=kevin.tian@intel.com \
    --cc=kvm@vger.kernel.org \
    --cc=laurentiu.tudor@nxp.com \
    --cc=leoyang.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=stuyoder@gmail.com \
    --cc=thierry.reding@gmail.com \
    --cc=will@kernel.org \
    --cc=yi.l.liu@intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.