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 > +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? What devices does "all present devices" cover? Is "tsm0" a special global thing? Is there doc for /sys/class/tsm/...? > +++ 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? Bjorn
