On Tue, Jan 30, 2024 at 01:24:14AM -0800, 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 CMA, component measurement and > authentication, and IDE, link integrity and data encryption. It adds > support for establishing virtual functions within a device that can be > assigned 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 device security manager (DSM) and > system software in both a VMM and a VM. 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. > > All vendor TSM implementations share the property of asking the VMM to > perform DOE mailbox operations on behalf of the TSM. That common > capability is centralized in PCI core code that invokes an ->exec() > operation callback potentially multiple times to service a given request > (struct pci_tsm_req). Future operations / verbs will be handled > similarly with the "request + exec" model. For now, only "connect" and > "disconnect" are implemented which at a minimum is expected to establish > IDE for the link. > > In addition to requests the low-level TSM implementation is notified of > device arrival and departure events so that it can filter devices that > the TSM is not prepared to support, or otherwise setup and teardown > per-device context. Gulp, this is a good start and covers a lot of what I asked about [1/5]. Should have read the whole series first ;)
