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
