linux-kernel - Re: [RFC PATCH 08/12] vfio/pci: Create host unaccessible dma-buf for private device

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: <67d0e549d4d27_201f029458@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 11 Mar 2025 18:37:13 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, Alexey Kardashevskiy <aik@....com>
CC: Baolu Lu <baolu.lu@...ux.intel.com>, Xu Yilun <yilun.xu@...ux.intel.com>,
	<kvm@...r.kernel.org>, <dri-devel@...ts.freedesktop.org>,
	<linux-media@...r.kernel.org>, <linaro-mm-sig@...ts.linaro.org>,
	<sumit.semwal@...aro.org>, <christian.koenig@....com>, <pbonzini@...hat.com>,
	<seanjc@...gle.com>, <alex.williamson@...hat.com>,
	<vivek.kasireddy@...el.com>, <dan.j.williams@...el.com>,
	<yilun.xu@...el.com>, <linux-coco@...ts.linux.dev>,
	<linux-kernel@...r.kernel.org>, <lukas@...ner.de>, <yan.y.zhao@...el.com>,
	<daniel.vetter@...ll.ch>, <leon@...nel.org>, <zhenzhong.duan@...el.com>,
	<tao1.su@...el.com>
Subject: Re: [RFC PATCH 08/12] vfio/pci: Create host unaccessible dma-buf for
 private device

[ My ears have been burning for a couple months regarding this thread
  and I have finally had the chance to circle back and read through all
  the discussion on PATCH 01/12 and this PATCH 08/12, pardon the latency
  while I addressed some CXL backlog ]

Jason Gunthorpe wrote:
> On Mon, Jan 20, 2025 at 08:45:51PM +1100, Alexey Kardashevskiy wrote:
> 
> > > For CC I'm expecting the KVM fd to be the handle for the cVM, so any
> > > RPCs that want to call into the secure world need the KVM FD to get
> > > the cVM's identifier. Ie a "bind to cVM" RPC will need the PCI
> > > information and the cVM's handle.
> > 
> > And keep KVM fd open until unbind? Or just for the short time to call the
> > PSP?
> 
> iommufd will keep the KVM fd alive so long as the vIOMMU object
> exists. Other uses for kvm require it to work like this.
> 
> > > But it also seems to me that VFIO should be able to support putting
> > > the device into the RUN state without involving KVM or cVMs.
> > 
> > AMD's TDI bind handler in the PSP wants a guest handle ("GCTX") and a guest
> > device BDFn, and VFIO has no desire to dive into this KVM business beyond
> > IOMMUFD.
> 
> As in my other email, VFIO is not restricted to running VMs, useful
> things should be available to apps like DPDK.
> 
> There is a use case for using TDISP and getting devices up into an
> ecrypted/attested state on pure bare metal without any KVM, VFIO
> should work in that use case too.

Are you sure you are not confusing the use case for native PCI CMA plus
PCIe IDE *without* PCIe TDISP? In other words validate device
measurements over a secure session and set up link encryption, but not
enable DMA to private memory. Without a cVM there is no private memory
for the device to talk to in the TDISP run state, but you can certainly
encrypt the PCIe link.

However that pretty much only gets you an extension of a secure session
to a PCIe link state. It does not enable end-to-end MMIO and DMA
integrity+confidentiality.

Note that to my knowledge all but the Intel TEE I/O implementation
disallow routing T=0 traffic over IDE. The host bridge only accepts T=1
traffic over IDE to private memory which is not this "without any KVM"
use case.

The uapi proposed in the PCI/TSM series [1] is all about the setup of PCI
CMA + PCIe IDE without KVM as a precuror to all the VFIO + KVM + IOMMUFD
work needed to get the TDI able to publish private MMIO and DMA to
private memory.

[1]: http://lore.kernel.org/174107245357.1288555.10863541957822891561.stgit@dwillia2-xfh.jf.intel.com