Re: [PATCH 00/11] PCI/TSM: Core infrastructure for PCI device security (TDISP)

[Greg KH <gregkh@linuxfoundation.org>]

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@dwillia2-xfh.jf.intel.com
> 
> ---
> 
> 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