Re: [PATCH 05/11] PCI/TSM: Authenticate devices via platform TSM

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

Alexey Kardashevskiy wrote:
[..]
> >> aik@sc ~> ls /sys/class/tsm-tdi/
> >> tdi:0000:c0:01.1  tdi:0000:e0:01.1  tdi:0000:e1:00.0  tdi:0000:e1:04.0
> >> tdi:0000:e1:04.1  tdi:0000:e1:04.2  tdi:0000:e1:04.3
> > 
> > Right, so I remain unconvinced that Linux needs to contend with new "tsm"
> > class devs vs PCI device objects with security properties especially
> > when those security properties have a "TSM" and non-"TSM" flavor.
> 
> One of the thoughts was - when we start adding this TDISP to CXL (which 
> is but also is not PCI), this may be handy, may be. Or, I dunno, 
> USB-TDISP. The security objects are described in the PCIe spec now but 
> the concept is generic really. Thanks,

I understand the temptation to consider "what if", but we have more than
enough complication and details to settle without the additional burden
of "maybe another bus will need this one day, so lets commit to a more
sophisticated (more device objects) ABI just in case".

For the specific case of CXL there is already the TSP specification. CXL
TSP does not call for any OS support beyond the existing memory
acceptance flow. I.e. CXL TSP pulls CXL.mem into the TCB just like DDR
does not need any enabling beyond asking the TSM if the physical address
supports shared-to-private memory conversion.

If another bus shows up tomorrow wanting to reuse the concepts there is
nothing stopping them from adding "authenticated", "tsm/connect", etc
attributes to their devices. So the proposed ABI is not tied to PCI.

The simple model of "device has security attributes" is scalable in a
way that "tdi child devices" is not. The statement, "the concept is
generic really", goes both ways. It implies not only "TDISP on other
buses", but also "device-security that is not TDISP". Unlike theoretical
"TDISP on other buses", "device-security that is not TDISP" is a
practical concern. It already has patches on the list.