linux-kernel - Re: [PATCH] iommu: Include MSI susceptibility to DMA in creating iommu groups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 23 Nov 2011 11:37:24 -0700
From:	Alex Williamson <alex.williamson@...hat.com>
To:	Chris Wright <chrisw@...s-sol.org>
Cc:	Joerg Roedel <joro@...tes.org>, iommu@...ts.linux-foundation.org,
	dwmw2@...radead.org, linux-kernel@...r.kernel.org,
	linux-pci@...r.kernel.org
Subject: Re: [PATCH] iommu: Include MSI susceptibility to DMA in creating
 iommu groups

On Mon, 2011-11-21 at 15:35 -0800, Chris Wright wrote:
> * Joerg Roedel (joro@...tes.org) wrote:
> > >From device standpoint a MSI transaction is always a DMA memory write
> > to a given address range. The IOMMU-API should export a feature flag
> > whether it supports filtering on those transaction or not. We have that
> > today with the IOMMU_CAP_INTR_REMAP. I agree that the interface to get
> > this information is ugly because a domain is needed. But the interface
> > can be fixed. While doing this I suggest to rename that feature
> > IOMMU_CAP_INTR_ISOLATION or something like that.
> > VFIO can then check for this flag on module-load and refuse to load if
> > it is not available.
> 
> I can see that the native grouping (the typical pci bridge type) is
> really more a property of the topology.
> 
> The isolation properties of a group (arguably the whole point of the
> group) is subtly different.

Yes, there is a subtle difference there, maybe that's what we're
tripping over.  I see the group as an assertion by the iommu driver that
it can distinguish and isolate the set of devices within that group from
other groups and shared resources.  For instance, numerous systems
include hardware iommus that provide only translation and not isolation
(DMA is translated through the IOVA window or allowed direct to memory).
That doesn't mean they should implement a device_group callback that
statically returns a single groupid, that means they should not
implement device_group.  I'm afraid the meaning of a group will be lost
if we allow iommus to define groups, but then add flags saying "oh, but
we don't isolate ________".  I much prefer we enable a user to opt-in at
the iommu driver level than weaken the definition of a group.  Thanks,

Alex

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/