Re: [RFC PATCH 5/5] PCI/TSM: Authenticate devices via platform TSM

[Dan Williams <dan.j.williams@intel.com>]

Bjorn Helgaas wrote:
> 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 ;)

I should have at least left a breadcrumb that the acronym soup is better
described in patch5. However, the specifications are certainly dense and
it is funny, in a laugh to keep from crying sort of way, that the
acronyms nest. "What do you mean the T in TDISP stands for TEE!?"

One interesting sidebar I had with Lukas about the naming was an
assertion that "Bjorn will want to call this the TDISP layer not the TSM
layer". The rationale being that the name of the PCIe specification
chapter that talks about the role of a 'TSM' is "Section 11. TEE Device
Interface Security Protocol (TDISP)". However, if there is one point I
want to get across in this posting is that TDISP is a protocol that is
spoken between the platform and the endpoint, i.e. between the TSM and
the DSM. A protocol abstracted away from Linux's view. Everything that
Linux needs to worry about is behind by the OS-to-TSM interface, and the
TDISP specification says next to nothing about what that OS-to-TSM
interface looks like. If it had standardized that, the job would be so
much easier.

So, I think Linux's role here is to act as a "standards body of last
resort" and try to hold platform definitions to a common understanding
of how much complexity is reasonable to export to Linux. Assert that the
per-platform portions intersect Linux at the same level of abstraction.
Basically, please no vendor-specific layering violations sprinkled
around the kernel, and enlighten the PCI core for core concepts (like
authentication). Do not build sidecars.