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: <20250410234457.GB63245@ziepe.ca>
Date: Thu, 10 Apr 2025 20:44:57 -0300
From: Jason Gunthorpe <jgg@...pe.ca>
To: Christoph Hellwig <hch@....de>
Cc: Dan Williams <dan.j.williams@...el.com>,
	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, 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 Thu, Apr 10, 2025 at 09:23:54AM +0200, Christoph Hellwig wrote:
> On Wed, Apr 09, 2025 at 04:30:17PM -0700, Dan Williams wrote:
> > > Thanks, I should've highlighted that facet most certainly!
> > 
> > One would hope that no one is building a modern device with trusted I/O
> > capability, *and* with a swiotlb addressing dependency. However, I agree
> > that a non-shared swiotlb would be needed in such a scenario.
> 
> Hope is never a good idea when dealing with hardware :(  PCIe already
> requires no addressing limitations, and programming interface specs
> like NVMe double down on that.  But at least one big hyperscaler still
> managed to build such a device.
> 
> Also even if the periphal device is not addressing limited, the root
> port or interconnect might still be, we've seen quite a lot of that.

Still it would be very obnoxious for someone to build a CC VM platform
where CC DMA devices can't access all the guest physical memory in the
CC address map :\

Keeping in mind that that the CC address map is being created by using
the CPU MMU and the CPU IOMMU so it is entirely virtual and can be
configured to match most problems the devices might have.

Too much memory would be the main issue..

IMHO I wouldn't implement secure SWIOTLB until someone does such a
foolish thing, and I'd make them do the work as some kind of pennance
:P

Jason