All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe via iommu <iommu@lists.linux-foundation.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.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,
	linux-pci@vger.kernel.org, Cornelia Huck <cohuck@redhat.com>,
	iommu@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
	Alex Williamson <alex.williamson@redhat.com>,
	Jacob jun Pan <jacob.jun.pan@intel.com>,
	Diana Craciun <diana.craciun@oss.nxp.com>,
	Bjorn Helgaas <bhelgaas@google.com>,
	Will Deacon <will@kernel.org>
Subject: Re: [PATCH 02/11] driver core: Set DMA ownership during driver bind/unbind
Date: Mon, 15 Nov 2021 09:38:15 -0400	[thread overview]
Message-ID: <20211115133815.GN2105516@nvidia.com> (raw)
In-Reply-To: <YZIFPv7BpsTibxE/@kroah.com>

On Mon, Nov 15, 2021 at 07:59:10AM +0100, Greg Kroah-Hartman wrote:
> > @@ -566,6 +567,12 @@ static int really_probe(struct device *dev, struct device_driver *drv)
> >  		goto done;
> >  	}
> >  
> > +	if (!drv->suppress_auto_claim_dma_owner) {
> > +		ret = iommu_device_set_dma_owner(dev, DMA_OWNER_KERNEL, NULL);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> 
> This feels wrong to be doing it in the driver core, why doesn't the bus
> that cares about this handle it instead?

As Christoph said, it is not related to the bus. To elaborate any
bus_type that has iommu_ops != NULL needs this check, and it must be
done on an individual struct device as the result is sensitive to the
iommu_group member of each struct device.

> You just caused all drivers in the kernel today to set and release this
> ownership, as none set this flag.  Shouldn't it be the other way around?

No - the whole point is to cause every driver to do this test.

iommu_device_set_dma_owner() can fail for any device, if it does then
a kernel driver must not be probed. Probing a kernel driver when
iommu_device_set_dma_owner() fails will break kernel integrity due to
HW limitations.

The drv->suppress_auto_claim_dma_owner disables this restriction
because three drivers will deal with DMA ownership on their own.

> You only have problems with 1 driver out of thousands, this feels wrong
> to abuse the driver core this way for just that one.

I think you have it backwards. Few drivers out of thousands can take
an action that impacts the security of a thousand other drivers.

The key thing is that device A can have a driver with
suppress_auto_claim_dma_owner=1 and call
iommu_device_set_dma_owner(DMA_OWNER_USER) which will then cause
another device B to be unsable in the kernel.

Device B, with a normal driver, must be prevented from having a kernel
driver because of what the special driver on device A did.

This behavior is a IOMMU HW limitation that cannot be avoided. The
restrictions have always been in the kernel, they were just enforced
with a BUG_ON at probe via a bus_notifier instead of a clean failure.

So, I don't know how to block probing of the thousands of drivers
without adding a test during probing, do you have an different idea?

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

WARNING: multiple messages have this Message-ID (diff)
From: Jason Gunthorpe <jgg@nvidia.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lu Baolu <baolu.lu@linux.intel.com>,
	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>,
	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>,
	iommu@lists.linux-foundation.org, linux-pci@vger.kernel.org,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 02/11] driver core: Set DMA ownership during driver bind/unbind
Date: Mon, 15 Nov 2021 09:38:15 -0400	[thread overview]
Message-ID: <20211115133815.GN2105516@nvidia.com> (raw)
In-Reply-To: <YZIFPv7BpsTibxE/@kroah.com>

On Mon, Nov 15, 2021 at 07:59:10AM +0100, Greg Kroah-Hartman wrote:
> > @@ -566,6 +567,12 @@ static int really_probe(struct device *dev, struct device_driver *drv)
> >  		goto done;
> >  	}
> >  
> > +	if (!drv->suppress_auto_claim_dma_owner) {
> > +		ret = iommu_device_set_dma_owner(dev, DMA_OWNER_KERNEL, NULL);
> > +		if (ret)
> > +			return ret;
> > +	}
> > +
> 
> This feels wrong to be doing it in the driver core, why doesn't the bus
> that cares about this handle it instead?

As Christoph said, it is not related to the bus. To elaborate any
bus_type that has iommu_ops != NULL needs this check, and it must be
done on an individual struct device as the result is sensitive to the
iommu_group member of each struct device.

> You just caused all drivers in the kernel today to set and release this
> ownership, as none set this flag.  Shouldn't it be the other way around?

No - the whole point is to cause every driver to do this test.

iommu_device_set_dma_owner() can fail for any device, if it does then
a kernel driver must not be probed. Probing a kernel driver when
iommu_device_set_dma_owner() fails will break kernel integrity due to
HW limitations.

The drv->suppress_auto_claim_dma_owner disables this restriction
because three drivers will deal with DMA ownership on their own.

> You only have problems with 1 driver out of thousands, this feels wrong
> to abuse the driver core this way for just that one.

I think you have it backwards. Few drivers out of thousands can take
an action that impacts the security of a thousand other drivers.

The key thing is that device A can have a driver with
suppress_auto_claim_dma_owner=1 and call
iommu_device_set_dma_owner(DMA_OWNER_USER) which will then cause
another device B to be unsable in the kernel.

Device B, with a normal driver, must be prevented from having a kernel
driver because of what the special driver on device A did.

This behavior is a IOMMU HW limitation that cannot be avoided. The
restrictions have always been in the kernel, they were just enforced
with a BUG_ON at probe via a bus_notifier instead of a clean failure.

So, I don't know how to block probing of the thousands of drivers
without adding a test during probing, do you have an different idea?

Jason

  parent reply	other threads:[~2021-11-15 13:38 UTC|newest]

Thread overview: 120+ 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 ` Lu Baolu
2021-11-15  2:05 ` [PATCH 01/11] iommu: Add device dma ownership set/release interfaces Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15 13:14   ` Christoph Hellwig
2021-11-15 13:14     ` Christoph Hellwig
2021-11-16  1:57     ` Lu Baolu
2021-11-16  1:57       ` Lu Baolu
2021-11-16 13:46       ` Jason Gunthorpe via iommu
2021-11-16 13:46         ` Jason Gunthorpe
2021-11-17  5:22         ` Lu Baolu
2021-11-17  5:22           ` Lu Baolu
2021-11-17 13:35           ` Jason Gunthorpe via iommu
2021-11-17 13:35             ` Jason Gunthorpe
2021-11-18  1:12             ` Lu Baolu
2021-11-18  1:12               ` Lu Baolu
2021-11-18 14:10               ` Jason Gunthorpe via iommu
2021-11-18 14:10                 ` Jason Gunthorpe
2021-11-18  2:39         ` Tian, Kevin
2021-11-18  2:39           ` Tian, Kevin
2021-11-18 13:33           ` Jason Gunthorpe via iommu
2021-11-18 13:33             ` Jason Gunthorpe
2021-11-19  5:44             ` Tian, Kevin
2021-11-19  5:44               ` Tian, Kevin
2021-11-19 11:14               ` Lu Baolu
2021-11-19 11:14                 ` Lu Baolu
2021-11-19 15:06                 ` Jörg Rödel
2021-11-19 15:06                   ` Jörg Rödel
2021-11-19 15:43                   ` Jason Gunthorpe via iommu
2021-11-19 15:43                     ` Jason Gunthorpe
2021-11-20 11:16                   ` Lu Baolu
2021-11-20 11:16                     ` Lu Baolu
2021-11-19 12:56               ` Jason Gunthorpe via iommu
2021-11-19 12:56                 ` Jason Gunthorpe
2021-11-15 20:38   ` Bjorn Helgaas
2021-11-15 20:38     ` Bjorn Helgaas
2021-11-16  1:52     ` Lu Baolu
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  2:05   ` Lu Baolu
2021-11-15  6:59   ` Greg Kroah-Hartman
2021-11-15  6:59     ` Greg Kroah-Hartman
2021-11-15 13:20     ` Christoph Hellwig
2021-11-15 13:20       ` Christoph Hellwig
2021-11-15 13:38     ` Jason Gunthorpe via iommu [this message]
2021-11-15 13:38       ` Jason Gunthorpe
2021-11-15 13:19   ` Christoph Hellwig
2021-11-15 13:19     ` Christoph Hellwig
2021-11-15 13:24     ` Jason Gunthorpe via iommu
2021-11-15 13:24       ` Jason Gunthorpe
2021-11-15 15:37       ` Robin Murphy
2021-11-15 15:37         ` Robin Murphy
2021-11-15 15:56         ` Jason Gunthorpe via iommu
2021-11-15 15:56           ` Jason Gunthorpe
2021-11-15 18:15           ` Christoph Hellwig
2021-11-15 18:15             ` Christoph Hellwig
2021-11-15 18:35           ` Robin Murphy
2021-11-15 18:35             ` Robin Murphy
2021-11-15 19:39             ` Jason Gunthorpe via iommu
2021-11-15 19:39               ` Jason Gunthorpe
2021-11-15  2:05 ` [PATCH 03/11] PCI: pci_stub: Suppress kernel DMA ownership auto-claiming Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15 13:21   ` Christoph Hellwig
2021-11-15 13:21     ` Christoph Hellwig
2021-11-15 13:31     ` Jason Gunthorpe via iommu
2021-11-15 13:31       ` Jason Gunthorpe
2021-11-15 15:14       ` Robin Murphy
2021-11-15 15:14         ` Robin Murphy
2021-11-15 16:17         ` Jason Gunthorpe via iommu
2021-11-15 16:17           ` Jason Gunthorpe
2021-11-15 17:54           ` Robin Murphy
2021-11-15 17:54             ` Robin Murphy
2021-11-15 18:19             ` Christoph Hellwig
2021-11-15 18:19               ` Christoph Hellwig
2021-11-15 18:44               ` Robin Murphy
2021-11-15 18:44                 ` Robin Murphy
2021-11-15 19:22             ` Jason Gunthorpe via iommu
2021-11-15 19:22               ` Jason Gunthorpe
2021-11-15 20:58               ` Robin Murphy
2021-11-15 20:58                 ` Robin Murphy
2021-11-15 21:19                 ` Jason Gunthorpe via iommu
2021-11-15 21:19                   ` Jason Gunthorpe
2021-11-15 20:48   ` Bjorn Helgaas
2021-11-15 20:48     ` Bjorn Helgaas
2021-11-15 22:17   ` Bjorn Helgaas
2021-11-15 22:17     ` Bjorn Helgaas
2021-11-16  6:05     ` Lu Baolu
2021-11-16  6:05       ` Lu Baolu
2021-11-15  2:05 ` [PATCH 04/11] PCI: portdrv: " Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15 20:44   ` Bjorn Helgaas
2021-11-15 20:44     ` Bjorn Helgaas
2021-11-16  7:24     ` Lu Baolu
2021-11-16  7:24       ` Lu Baolu
2021-11-16 20:22       ` Bjorn Helgaas
2021-11-16 20:22         ` Bjorn Helgaas
2021-11-16 20:48         ` Jason Gunthorpe via iommu
2021-11-16 20:48           ` Jason Gunthorpe
2021-11-15  2:05 ` [PATCH 05/11] iommu: Add security context management for assigned devices Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15 13:22   ` Christoph Hellwig
2021-11-15 13:22     ` Christoph Hellwig
2021-11-16  7:25     ` Lu Baolu
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  2:05   ` Lu Baolu
2021-11-15 13:27   ` Christoph Hellwig
2021-11-15 13:27     ` Christoph Hellwig
2021-11-16  9:42     ` Lu Baolu
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   ` Lu Baolu
2021-11-15  2:05 ` [PATCH 08/11] vfio: Remove use of vfio_group_viable() Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15  2:05 ` [PATCH 09/11] vfio: Delete the unbound_list Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15  2:05 ` [PATCH 10/11] vfio: Remove iommu group notifier Lu Baolu
2021-11-15  2:05   ` Lu Baolu
2021-11-15  2:05 ` [PATCH 11/11] iommu: Remove iommu group changes notifier Lu Baolu
2021-11-15  2:05   ` 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=20211115133815.GN2105516@nvidia.com \
    --to=iommu@lists.linux-foundation.org \
    --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=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 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.