[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d7ca046e-37fe-937b-d7cf-55af3839f0a0@linux.intel.com>
Date: Tue, 4 Jan 2022 13:23:02 +0800
From: Lu Baolu <baolu.lu@...ux.intel.com>
To: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Joerg Roedel <joro@...tes.org>,
Alex Williamson <alex.williamson@...hat.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Jason Gunthorpe <jgg@...dia.com>,
Christoph Hellwig <hch@...radead.org>,
Kevin Tian <kevin.tian@...el.com>,
Ashok Raj <ashok.raj@...el.com>
Cc: baolu.lu@...ux.intel.com, Will Deacon <will@...nel.org>,
Robin Murphy <robin.murphy@....com>,
Dan Williams <dan.j.williams@...el.com>, rafael@...nel.org,
Diana Craciun <diana.craciun@....nxp.com>,
Cornelia Huck <cohuck@...hat.com>,
Eric Auger <eric.auger@...hat.com>,
Liu Yi L <yi.l.liu@...el.com>,
Jacob jun Pan <jacob.jun.pan@...el.com>,
Chaitanya Kulkarni <kch@...dia.com>,
Stuart Yoder <stuyoder@...il.com>,
Laurentiu Tudor <laurentiu.tudor@....com>,
Thierry Reding <thierry.reding@...il.com>,
David Airlie <airlied@...ux.ie>,
Daniel Vetter <daniel@...ll.ch>,
Jonathan Hunter <jonathanh@...dia.com>,
Li Yang <leoyang.li@....com>,
Dmitry Osipenko <digetx@...il.com>,
iommu@...ts.linux-foundation.org, linux-pci@...r.kernel.org,
kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 00/13] Fix BUG_ON in vfio_iommu_group_notifier()
On 12/17/21 2:36 PM, Lu Baolu wrote:
> Hi folks,
>
> The iommu group is the minimal isolation boundary for DMA. Devices in
> a group can access each other's MMIO registers via peer to peer DMA
> and also need share the same I/O address space.
>
> Once the I/O address space is assigned to user control it is no longer
> available to the dma_map* API, which effectively makes the DMA API
> non-working.
>
> Second, userspace can use DMA initiated by a device that it controls
> to access the MMIO spaces of other devices in the group. This allows
> userspace to indirectly attack any kernel owned device and it's driver.
>
> Therefore groups must either be entirely under kernel control or
> userspace control, never a mixture. Unfortunately some systems have
> problems with the granularity of groups and there are a couple of
> important exceptions:
>
> - 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
> it.
>
> - PCI bridges are sometimes included in groups. Typically PCI bridges
> do not use DMA, and generally do not have MMIO regions.
>
> Generally any device that does not have any MMIO registers is a
> possible candidate for an exception.
>
> Currently vfio adopts a workaround to detect violations of the above
> restrictions by monitoring the driver core BOUND event, and hardwiring
> the above exceptions. Since there is no way for vfio to reject driver
> binding at this point, BUG_ON() is triggered if a violation is
> captured (kernel driver BOUND event on a group which already has some
> devices assigned to userspace). Aside from the bad user experience
> this opens a way for root userspace to crash the kernel, even in high
> integrity configurations, by manipulating the module binding and
> triggering the BUG_ON.
>
> This series solves this problem by making the user/kernel ownership a
> core concept at the IOMMU layer. The driver core enforces kernel
> ownership while drivers are bound and violations now result in a error
> codes during probe, not BUG_ON failures.
>
> Patch partitions:
> [PATCH 1-4]: Detect DMA ownership conflicts during driver binding;
> [PATCH 5-8]: Add security context management for assigned devices;
> [PATCH 9-13]: Various cleanups.
>
> This is also part one of three initial series for IOMMUFD:
> * Move IOMMU Group security into the iommu layer
> - Generic IOMMUFD implementation
> - VFIO ability to consume IOMMUFD
>
> Change log:
> v1: initial post
> - https://lore.kernel.org/linux-iommu/20211115020552.2378167-1-baolu.lu@linux.intel.com/
>
> v2:
> - https://lore.kernel.org/linux-iommu/20211128025051.355578-1-baolu.lu@linux.intel.com/
>
> - Move kernel dma ownership auto-claiming from driver core to bus
> callback. [Greg/Christoph/Robin/Jason]
> https://lore.kernel.org/linux-iommu/20211115020552.2378167-1-baolu.lu@linux.intel.com/T/#m153706912b770682cb12e3c28f57e171aa1f9d0c
>
> - Code and interface refactoring for iommu_set/release_dma_owner()
> interfaces. [Jason]
> https://lore.kernel.org/linux-iommu/20211115020552.2378167-1-baolu.lu@linux.intel.com/T/#mea70ed8e4e3665aedf32a5a0a7db095bf680325e
>
> - [NEW]Add new iommu_attach/detach_device_shared() interfaces for
> multiple devices group. [Robin/Jason]
> https://lore.kernel.org/linux-iommu/20211115020552.2378167-1-baolu.lu@linux.intel.com/T/#mea70ed8e4e3665aedf32a5a0a7db095bf680325e
>
> - [NEW]Use iommu_attach/detach_device_shared() in drm/tegra drivers.
>
> - Refactoring and description refinement.
>
> v3:
> - https://lore.kernel.org/linux-iommu/20211206015903.88687-1-baolu.lu@linux.intel.com/
>
> - Rename bus_type::dma_unconfigure to bus_type::dma_cleanup. [Greg]
> https://lore.kernel.org/linux-iommu/c3230ace-c878-39db-1663-2b752ff5384e@linux.intel.com/T/#m6711e041e47cb0cbe3964fad0a3466f5ae4b3b9b
>
> - Avoid _platform_dma_configure for platform_bus_type::dma_configure.
> [Greg]
> https://lore.kernel.org/linux-iommu/c3230ace-c878-39db-1663-2b752ff5384e@linux.intel.com/T/#m43fc46286611aa56a5c0eeaad99d539e5519f3f6
>
> - Patch "0012-iommu-Add-iommu_at-de-tach_device_shared-for-mult.patch"
> and "0018-drm-tegra-Use-the-iommu-dma_owner-mechanism.patch" have
> been tested by Dmitry Osipenko <digetx@...il.com>.
>
> v4:
> - Remove unnecessary tegra->domain chech in the tegra patch. (Jason)
> - Remove DMA_OWNER_NONE. (Joerg)
> - Change refcount to unsigned int. (Christoph)
> - Move mutex lock into group set_dma_owner functions. (Christoph)
> - Add kernel doc for iommu_attach/detach_domain_shared(). (Christoph)
> - Move dma auto-claim into driver core. (Jason/Christoph)
Thank you very much for the review comments. A new version has been
posted.
https://lore.kernel.org/linux-iommu/20220104015644.2294354-1-baolu.lu@linux.intel.com/
Best regards,
baolu
Powered by blists - more mailing lists