On Thu, Dec 05, 2024 at 02:23:15PM -0800, Dan Williams wrote: > Changes since the RFC [1]: > - Wording changes and cleanups in "PCI/TSM: Authenticate devices via > platform TSM" (Bjorn) > - Document /sys/class/tsm/tsm0 (Bjorn) > - Replace the single ->exec(@op_code) operation with named operations > (Alexey, Yilun) > - Locking fixup in drivers/pci/tsm.c (Yilun) > - Drop pci_tsm_devs xarray (Alexey, Yilun) > - Finish the host bridge stream id allocator implementation (Alexey) > - Clarify pci_tsm_init() relative to IDE && !TEE devices (Alexey) > - Add the IDE core helpers > - Add devsec_tsm and devsec_bus sample driver and emulation > > [1]: http://lore.kernel.org/171291190324.3532867.13480405752065082171.stgit@xxxxxxxxxxxxxxxxxxxxxxxxx > > --- > > Trusted execution environment (TEE) Device Interface Security Protocol > (TDISP) is a chapter name in the PCI specification. It describes an > alphabet soup of mechanisms, SPDM, CMA, IDE, TSM/DSM, that system > software uses to establish trust in a device and assign it to a > confidential virtual machine (CVM). It is protocol for dynamically > extending the trusted computing boundary (TCB) of a CVM with a PCI > device interface that can issue DMA to CVM private memory. > > The acronym soup problem is enhanced by every major platform vendor > having distinct TEE Security Manager (TSM) API implementations / > capabilities, and to a lesser extent, every potential endpoint Device > Security Manager (DSM) having its own idiosyncratic behaviors around > TDISP state transitions. Wow, you aren't kidding about the acronym soup problem, this is a mess. And does any of this relate to the existing drivers/tee/ subsystem in any way? Anyhow, this patch series looks sane, nice work. > Note that devsec_tsm is for near term staging of vendor TSM > implementations. The expectation is that every piece of new core > infrastructure that devsec_tsm consumes must also have a vendor TSM > driver consumer within 1 to 2 kernel development cycles. How are you going to enforce this? By removing infrastructure? Normally we can't add infrastructure unless there's a real user, and when you add a real user then you see all the things that need to be chagned. So are you ok with the apis and interfaces moving around over time here? I think I only see sysfs files being exported so hopefully this shouldn't be that big of a deal for userspace to deal with, but I don't know what userspace is supposed to do with any of this, is there external tools to talk to / set up, these devices? thanks, greg k-h
