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] [day] [month] [year] [list]

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

Michael Kelley wrote:
> From: Dan Williams <dan.j.williams@...el.com> Sent: Wednesday, April 9, 2025 4:30 PM
[..]
> > Like PCIe TDISP the capability of this device to access private memory
> > is a property of the bus and the iommu. However, acceptance of the
> > device into private operation is a willful policy action. It needs to
> > validate not only the device provenance and state, but also the Linux
> > DMA layer requirements of not holding shared or swiotlb mappings over
> > the "entry into private mode operation" event.
> 
> To flesh this out the swiotlb aspect a bit, once a TDISP device has
> gone private, how does it prevent the DMA layer from ever doing
> bounce buffering through the swiotlb? My understanding is that
> the DMA layer doesn't make any promises to not do bounce buffering.
> Given the vagaries of memory alignment, perhaps add in a virtual
> IOMMU, etc., it seems like a device driver can't necessarily predict
> what DMA operations might result in bounce buffering. Does TDISP
> anticipate needing a formal way to tell the DMA layer "don't bounce
> buffer"? (and return an error instead?) Or would there be a separate
> swiotlb memory pool that is private memory so that bounce buffer
> could be done when necessary and still maintain confidentiality?

I expect step 1 is just add some rude errors / safety for attempting to
convert the mode of a device while it has any DMA mappings established,
and explicit failures for attempts to fallback to swiotlb for
'private_accepted' devices.

The easiest way to enforce that a device does not cross the
shared/private boundary while DMA mappings are live is to simply not
allow that transition while a driver is bound (i.e. "dev->driver" is
non-NULL).