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.
