linux-kernel - Re: [PATCH hyperv-next 5/6] arch, drivers: Add device struct bitfield to not bounce-buffer

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]

Message-ID: <20250410235008.GC63245@ziepe.ca>
Date: Thu, 10 Apr 2025 20:50:08 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Dan Williams <dan.j.williams@...el.com>
Cc: Roman Kisel <romank@...ux.microsoft.com>,
	Robin Murphy <robin.murphy@....com>, aleksander.lobakin@...el.com,
	andriy.shevchenko@...ux.intel.com, arnd@...db.de, bp@...en8.de,
	catalin.marinas@....com, corbet@....net, dakr@...nel.org,
	dave.hansen@...ux.intel.com, decui@...rosoft.com,
	gregkh@...uxfoundation.org, haiyangz@...rosoft.com, hch@....de,
	hpa@...or.com, James.Bottomley@...senpartnership.com,
	Jonathan.Cameron@...wei.com, kys@...rosoft.com, leon@...nel.org,
	lukas@...ner.de, luto@...nel.org, m.szyprowski@...sung.com,
	martin.petersen@...cle.com, mingo@...hat.com, peterz@...radead.org,
	quic_zijuhu@...cinc.com, tglx@...utronix.de, wei.liu@...nel.org,
	will@...nel.org, iommu@...ts.linux.dev, linux-arch@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, linux-doc@...r.kernel.org,
	linux-hyperv@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org, x86@...nel.org, apais@...rosoft.com,
	benhill@...rosoft.com, bperkins@...rosoft.com,
	sunilmut@...rosoft.com, Suzuki K Poulose <suzuki.poulose@....com>,
	linux-coco@...ts.linux.dev
Subject: Re: [PATCH hyperv-next 5/6] arch, drivers: Add device struct
 bitfield to not bounce-buffer

On Wed, Apr 09, 2025 at 04:30:17PM -0700, Dan Williams wrote:

> Like Christoph said, a driver really has no business opting itself into
> different DMA addressing domains. For TDISP we are also being careful to
> make sure that flipping a device from shared to private is a suitably
> violent event. This is because the Linux DMA layer does not have a
> concept of allowing a device to have mappings from two different
> addressing domains simultaneously.

And this is a very important point, several of the architectures have
two completely independent iommu tables, and maybe even completely
different IOMMU instances for trusted and non-trusted DMA traffic.

I expect configurations where trusted traffic is translated through
the vIOMMU while non-trusted traffic is locked to an identity
translation.

There are more issue here than just swiotlb :\

> A "private_capable" flag might also make sense, but that is really a
> property of a bus that need not be carried necessarily in 'struct
> device'.

However it works, it should be done before the driver is probed and
remain stable for the duration of the driver attachment. From the
iommu side the correct iommu domain, on the correct IOMMU instance to
handle the expected traffic should be setup as the DMA API's iommu
domain.

Jason