Bjorn Helgaas wrote: > On Fri, Apr 12, 2024 at 01:52:13AM -0700, Dan Williams wrote: > > The PCIe 6.1 specification, section 11, introduces the Trusted Execution > > Environment (TEE) Device Interface Security Protocol (TDISP). This > > interface definition builds upon Component Measurement and > > Authentication (CMA), and link Integrity and Data Encryption (IDE). It > > adds support for assigning devices (PCI physical or virtual function) to > > a confidential VM such that the assigned device is enabled to access > > guest private memory protected by technologies like Intel TDX, AMD > > SEV-SNP, RISCV COVE, or ARM CCA. > > > > The "TSM" (TEE Security Manager) is a concept in the TDISP specification > > of an agent that mediates between a "DSM" (Device Security Manager) and > > system software in both a VMM and a confidential VM. A VMM uses TSM ABIs > > to setup link security and assign devices. A confidential VM uses TSM > > ABIs to transition an assigned device into the TDISP "RUN" state and > > validate its configuration. From a Linux perspective the TSM abstracts > > many of the details of TDISP, IDE, and CMA. Some of those details leak > > through at times, but for the most part TDISP is an internal > > implementation detail of the TSM. > > > > Similar to the PCI core extensions to support CONFIG_PCI_CMA, > > CONFIG_PCI_TSM builds upon that to reuse the "authenticated" sysfs > > attribute, and add more properties + controls in a tsm/ subdirectory of > > the PCI device sysfs interface. Unlike CMA that can depend on a local to > > the PCI core implementation, PCI_TSM needs to be prepared for late > > loading of the platform TSM driver. Consider that the TSM driver may > > itself be a PCI driver. Userspace can depend on the common TSM device > > uevent to know when the PCI core has TSM services enabled. The PCI > > device tsm/ subdirectory is supplemented by the TSM device pci/ > > directory for platform global TSM properties + controls. > > > > The common verbs that the low-level TSM drivers implement are defined by > > 'enum pci_tsm_cmd'. For now only connect and disconnect are defined for > > establishing a trust relationship between the host and the device, > > securing the interconnect (optionally establishing IDE), and tearing > > that down. > > > > The locking allows for multiple devices to be executing commands > > simultaneously, one outstanding command per-device and an rwsem flushes > > all inflight commands when a TSM low-level driver/device is removed. > > > > In addition to commands submitted through an 'exec' operation the > > low-level TSM driver is notified of device arrival and departure events > > via 'add' and 'del' operations. With those it can setup per-device > > context, or filter devices that the TSM is not prepared to support. > > > > Cc: Wu Hao <hao.wu@xxxxxxxxx> > > Cc: Yilun Xu <yilun.xu@xxxxxxxxx> > > Cc: Lukas Wunner <lukas@xxxxxxxxx> > > Cc: Samuel Ortiz <sameo@xxxxxxxxxxxx> > > Cc: Alexey Kardashevskiy <aik@xxxxxxx> > > Cc: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> > > Co-developed-by: Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx> > > Signed-off-by: Xu Yilun <yilun.xu@xxxxxxxxxxxxxxx> > > Signed-off-by: Dan Williams <dan.j.williams@xxxxxxxxx> > > Acked-by: Bjorn Helgaas <bhelgaas@xxxxxxxxxx> # PCI parts Great, thanks Bjorn! This lets us move forward on the TSM details knowing that it looks like this meets your expectations on the PCI integration aspects. Will continue to include you on revisions as this evolves, but this is good news for the cross vendor collaboration effort in process here. > > +What: /sys/bus/pci/devices/.../tsm/ > > +Date: March 2024 > > +Contact: linux-coco@xxxxxxxxxxxxxxx > > +Description: > > + This directory only appears if a device supports CMA and IDE, > > + and only after a TSM driver has loaded and evaluated this > > + PCI device. All present devices shall be dispositioned > > + after the 'add' event for /sys/class/tsm/tsm0 triggers. > > What does "dispositioned" mean? When /sys/class/tsm/tsm0/uevent signals KOBJ_ADD, arrival of the TSM device, a udev script can assume that the kernel has walked all PCI devices and toggled the visibility of the all /sys/bus/pci/devices/$pdev/tsm/ attribute directories. > What devices does "all present devices" cover? A snapshot of the state of /sys/bus/pci/devices at TSM arrival. So a udev script that, for example, wants to perform the TSM "connect" operation as soon as possible should watch PCI KOBJ_ADD uevents and try to connect if the TSM is present at that time, but if not, try again after TSM KOBJ_ADD. Similar for the PCI-hot-add case. TSM may arrive first, so that policy script should recheck when PCI KOBJ_ADD, for the device it wants to connect, fires. > > Is "tsm0" a special global thing? Is there doc for > /sys/class/tsm/...? Yes, it is a special common object that any platform with a TSM will export. I had yet to create a document since there are no common attributes defined in this version of the patch set, but I can go ahead and create it and mention what userspace can expect about the state of /sys/bus/pci/devices when the device shows up. > > > +++ b/drivers/pci/Makefile > > @@ -35,6 +35,8 @@ obj-$(CONFIG_VGA_ARB) += vgaarb.o > > obj-$(CONFIG_PCI_DOE) += doe.o > > obj-$(CONFIG_PCI_DYNAMIC_OF_NODES) += of_property.o > > > > +obj-$(CONFIG_PCI_TSM) += tsm.o > > Maybe put it next to CONFIG_PCI_DOE or at least not off in a special > separate list? Sure, will do.
