linux-kernel - Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use of SWIOTLB bounce buffers

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: <06465bcf4422d088df2a0ce9cdb09767dac83118.camel@infradead.org>
Date: Thu, 03 Apr 2025 08:37:20 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Christoph Hellwig <hch@...radead.org>
Cc: "Michael S. Tsirkin" <mst@...hat.com>, virtio-comment@...ts.linux.dev, 
 Claire Chang <tientzu@...omium.org>, linux-devicetree
 <devicetree@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>,
 Jörg Roedel <joro@...tes.org>, 
 iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
 graf@...zon.de
Subject: Re: [RFC PATCH 1/3] content: Add VIRTIO_F_SWIOTLB to negotiate use
 of SWIOTLB bounce buffers

On Thu, 2025-04-03 at 00:29 -0700, Christoph Hellwig wrote:
> On Wed, Apr 02, 2025 at 06:10:53PM +0100, David Woodhouse wrote:
> > > I know a bit more about PCI, and for PCI I prefer just not saying
> > > anything. The platform already defines whether it is behind an iommu
> > > or not, and duplication is not good.
> > 
> > Not a hill for me to die on I suppose, but I would personally prefer to
> > spell it out in words of one syllable or fewer, to make *sure* that
> > device and driver authors get it right even though it's "obvious".
> > 
> > After all, if we could trust them to do their thinking, we would never
> > have had the awful situation that led to VIRTIO_F_ACCESS_PLATFORM
> > existing in the first place; the legacy behaviour we get when that bit
> > *isn't* set would never have happened.
> 
> You'll need to define the semanics for VIRTIO_F_ACCESS_PLATFORM only
> then.  
> 

You mean the semantics for VIRTIO_F_ACCESS_PLATFORM only, without
VIRTIO_F_SWIOTLB? Are those not defined already?

> An the only sane answer there is: don't allow non-translated
> regions at all an in a broader sense stop people to use
> VIRTIO_F_ACCESS_PLATFORM at all or at least for anything that requires
> a new feature bit.
> 
> > > For mmio it is my understanding that the "restricted" does the same
> > > already? or is it required in the spec for some reason?
> > 
> > No, it's exactly the same. But I still don't trust driver authors to
> > realise the obvious, or VMM implementations either for that matter.
> > 
> > I'm not sure I see the *harm* in spelling out explicitly for the hard-
> > of-thinking.
> 
> Write a whitepaper than and explain how it maps to the existing perfectly
> working features.  Note that VIRTIO_F_ACCESS_PLATFORM just like
> everything in virtio would actually benefit from being turned into
> proper spec language, but anecdotes about random use cases are not
> helpful.

Hm. I was just trying to point out what seemed obvious, that when a PCI
device does 'DMA' to an address region which is actually within one of
its *own* BARs, it isn't going to reach the PCI bus and get translated
by an IOMMU. If it's causing this much contention, I'll just drop it.
It didn't *change* anything anyway, except hopefully avoiding bugs in
implementations.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (5069 bytes)