Re: [PATCH v5 04/10] PCI/TSM: Authenticate devices via platform TSM

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

Alexey Kardashevskiy wrote:
> 
> 
> On 9/9/25 11:52, dan.j.williams@intel.com wrote:
> > Alexey Kardashevskiy wrote:
> >>
> >>
> >> On 9/9/25 10:41, dan.j.williams@intel.com wrote:
> >>> Alexey Kardashevskiy wrote:
> >>>>> So PCI_EXP_DEVCAP_TEE means that there may be a DSM,
> >>>>
> >>>> This bit I am not sure about. A bit hard to believe that PF0 is always expected to support passing through to a CVM. Thanks,
> >>>
> >>> I am losing track of your specific feedback, or what changes or being
> >>
> >> I've reread the thread, I wrongly assumed "tee" is used to decide whether to show "connect" in sysfs or not. I guess I was a bit tired^woverwhelmed when I made that comment, my bad.
> >>
> >>
> >>> suggested here is the summary of what the spec assumptions and what the
> >>> core supports:
> >>>
> >>> Spec assumptions:
> >>> - DEVCAP_TEE on a physical function is independent of IDE cap
> >>
> >> Right, I just want to make sure that PF0 that manages TEE VFs does not have to have the TEE bit itself.
> > 
> > It does. Otherwise, how do you tell the difference between a device that
> > that only supports Component Measurement and Authentication (CMA) in
> > isolation vs a device that support CMA *and* TDISP requests?
> 
> I'd check for IDE (not just CMA)

Again, IDE is optional for TDISP.

In section "11.1 Overview of the TEE-I/O Security Model as it Relates to
Devices" it says:

    In some cases, e.g. for an RCiEP, it may be possible to ensure by
    construction that communication is not be susceptible to tampering, and
    therefore may not require the use of IDE. The TSM and DSM are both
    responsible for ensuring that Device/Host (and, when peer-to-peer is
    used, Device/Device) communication is secured by IDE, or by other means
    that satisfy use model requirements.

> and then I'll ask the TSM about TDISP (my PSP asks the PF0 for TDISP
> version at the very end of DEV_CONNECT). It is the TSM which does all
> this IDE_KM and TDISP stuff anyway.
> 
> And how do I tell if PF0 allows TDIs or not? Try binding and see it
> failing if it does not? Same thing imho.

Yes, the specification does not define a way, unless I missed it, to
enumerate the valid set of interface ids that the DSM manages. So the
best Linux can do is say "device is a function 0 endpoint and has
DEVCAP_TEE, lets assume that it manages SR-IOV functions, or non-zero
functions of the device. If the device is an upstream switch port, then
assume that it is a DSM for downstream secondary bus devices".

Those assumptions can not be validated in advance of trying to bind the
function. I.e. punt to userspace to figure it out the dependencies.

> > Now, the PCI/TSM core will still attach if that PF0 device has IDE,
> > without DEVCAP_TEE, but that support is incidental.
> 
> Sure, I am trying to clarify the PCIe language here, none of this is a
> showstopper really. Thanks,

Again I am confused if you are pointing out a functional incompatibility
with the hardware you have in hand or are just trying to compare
interpretations of the specification.