Re: [PATCH v2 1/1] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"

From: Christoph Hellwig <hch@infradead.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	"Martin K. Petersen" <martin.petersen@oracle.com>,
	Tom Lendacky <thomas.lendacky@amd.com>,
	"James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Michael S. Tsirkin" <mst@redhat.com>,
	"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Halil Pasic <pasic@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	iommu <iommu@lists.linux-foundation.org>,
	Doug Gilbert <dgilbert@interlog.com>,
	Anshuman Khandual <khandual@linux.vnet.ibm.com>,
	Robin Murphy <robin.murphy@arm.com>,
	Thiago Jung Bauermann <bauerman@linux.ibm.com>
Subject: Re: [PATCH v2 1/1] swiotlb: rework "fix info leak with DMA_FROM_DEVICE"
Date: Sat, 5 Mar 2022 23:58:48 -0800	[thread overview]
Message-ID: <YiRpuGbjyU2M47pQ@infradead.org> (raw)
In-Reply-To: <CAHk-=wgZ6fNG03pd2pAVw9RtymwPDyHNvTLHr2Q3LX3S0Y1k5Q@mail.gmail.com>

On Sat, Mar 05, 2022 at 11:44:51AM -0800, Linus Torvalds wrote:
> Christoph, I am assuming I'll get this from you, but if you have
> nothing else pending, just holler and I can take it directly.

I have nothing else pending, so feel free to take it directly:

Reviewed-by: Christoph Hellwig <hch@lst.de>

> That said, it seems sad to bounce the buffer just in case the device
> doesn't do what we expect it to do. Wouldn't it be better to just
> clear the buffer instead of copying the old data into it?

That unfortunately does not work always work, as we have interfaces
where we expect data that is not written to by the device to remain
unchanged, and there are many cases where the device does not write
the whole buffer.  In various places like SCSI the data transfer
can be smaller, but even more common is the case of no data transfer
at all error cases.

> Also, possibly stupid question - when is swiotlb used in practice
> these days? What are the performance implications of this? Will this
> mean completely unnecessary copies for all normal IO that will be
> overwritten by the DMA? Can't we limit it to just SG_IO (or is it
> already for some reason)?

There are three use case:
 - bounce buffering due to address limitations when no IOMMU is present
 - bounce buffering for not page aligned I/O on IOMMUs if the device
   is considered untrusted (which りight now means thunderbolt attached)
 - unconditional bounce buffering for trusted hypervisor schemes

All of thee apply to all I/O.  SG_IO is just a vector here as a
particularly badly designed userspace interface that happens to get a
decent test coverage.  There unfortuately are plenty of other ways to
expose this issue as well.  We're thinking of building interfaces to
avoid the overhead for well designed interfaces, but it will take some
time.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu