Re: TDISP enablement

[Alexey Kardashevskiy <aik@amd.com>]

On 1/11/23 18:27, Lukas Wunner wrote:
> On Wed, Nov 01, 2023 at 09:56:11AM +1100, Alexey Kardashevskiy wrote:
>> - device_connect - starts CMA/SPDM session, returns measurements/certs,
>> runs IDE_KM to program the keys;
> 
> Does the PSP have a set of trusted root certificates?
> If so, where does it get them from?
> 
> If not, does the PSP just blindly trust the validity of the cert chain?

The PSP does trust, or "does not care".

> Who validates the cert chain, and when?

The guest validates, before enabling MMIO/IOMMU.

> Which slot do you use?

The slot number is passed to the PSP at the device setup in the PSP 
("device_connect").

> Do you return only the cert chain of that single slot or of all slots?
> Does the PSP read out all measurements available? 

All or a digest (hash).

> This may take a while
> if the measurements are large and there are a lot of them.

Hm. May be. The PSP can return either all measurements or just a digest. 
The host is supposed to cache it.

> 
>> - tdi_info - read measurements/certs/interface report;
> 
> Does this return cached cert chains and measurements from the device
> or does it retrieve them anew?  (Measurements might have changed if
> MEAS_FRESH_CAP is supported.)

It returns the digests and a flag saying if these are from before or 
after the device was TDISP-locked (tdi_bind).


>> If the user wants only CMA/SPDM, the Lukas'es patched will do that without
>> the PSP. This may co-exist with the AMD PSP (if the endpoint allows multiple
>> sessions).
> 
> It can co-exist if the pci_cma_claim_ownership() library call
> provided by patch 12/12 is invoked upon device_connect.
> 
> It would seem advantageous if you could delay device_connect
> until a device is actually passed through. 

It is not exactly a whole device which is passed through but likely just 
a VF, just to clarify.

> Then the OS can
> initially authenticate and measure devices and the PSP takes
> over when needed.

The PSP is going to redo all this anyway so at least in my case it is 
just unwanted duplication. Although I am still not sure if 2 SPDM 
sessions cannot co-exist (not that I want that in particular though).


>> If the user wants only IDE, the AMD PSP's device_connect needs to be called
>> and the host OS does not get to know the IDE keys. Other vendors allow
>> programming IDE keys to the RC on the baremetal, and this also may co-exist
>> with a TSM running outside of Linux - the host still manages trafic classes
>> and streams.
> 
> I'm wondering if your implementation is spec compliant:
> 
> PCIe r6.1 sec 6.33.3 says that "It is permitted for a Root Complex
> to [...] use implementation specific key management."  But "For
> Endpoint Functions, [...] Function 0 must implement [...]
> the IDE key management (IDE_KM) protocol as a Responder."
> 
> So the keys need to be programmed into the endpoint using IDE_KM
> but for the Root Port it's permitted to use implementation-specific
> means.

Correct.
> The keys for the endpoint and Root Port are the same because this
> is symmetric encryption.
> 
> If the keys are internal to the PSP, the kernel can't program the
> keys into the endpoint using IDE_KM.  So your implementation precludes
> IDE setup by the host OS kernel.

Correct.

> device_connect is meant to be used for TDISP, i.e. with devices which
> have the TEE-IO Supported bit set in the Device Capabilities Register.
> 
> What are you going to do with IDE-capable devices which have that bit
> cleared?  Are they unsupported by your implementation?

It should be possible to call just "device_connect" to have IDE set up.

> It seems to me an architecture cannot claim IDE compliance if it's
> limited to TEE-IO capable devices, which might only be a subset of
> the available products.
> 
>> The next steps:
>> - expose blobs via configfs (like Dan did configfs-tsm);
>> - s/tdisp.ko/coco.ko/;
>> - ask the audience - what is missing to make it reusable for other vendors
>> and uses?
> 
> I intend to expose measurements in sysfs in a measurements/ directory
> below each CMA-capable device's directory.  There are products coming
> to the market which support only CMA and are not interested in IDE or
> TISP.  When bringing up TDISP, measurements received as part of an
> interface report must be exposed in the same way so that user space
> tooling which evaluates the measurememt works both with TEE-IO capable
> and incapable products.  This could be achieved by fetching measurements
> from the interface report instead of via SPDM when TDISP is in use.

Out of curiosity - sysfs, not configfs?

> 
> Thanks,
> 
> Lukas

-- 
Alexey