Alexey Kardashevskiy wrote: [..] > > Next bit probably has holes... Key is that a lot of the checks > > may fail, and it's up to host userspace policy to decide whether > > to proceed (other policy in the secure VM side of things obviously) > > > > So my rough thinking is - for the two options (IDE / TDISP) > > > > Comparing with Alexey's flow I think only real difference is that > > I call out explicit host userspace policy controls. I'd also like > > My imagination fails me :) What is the host supposed to do if the device > verification fails/succeeds later, and how much later, and the device is > a boot disk? Or is this userspace going to be limited to initramdisk? > What is that thing which we are protecting against? Or it is for CUDA > and such (which yeah, it can wait)? > > > to use similar interfaces to convey state to host userspace as > > per Lukas' existing approaches. Sure there will also be in > > kernel interfaces for driver to get data if it knows what to do > > with it. I'd also like to enable the non tdisp flow to handle > > IDE setup 'natively' if that's possible on particular hardware. > > > > 1. Host has a go at CMA/SPDM. Policy might say that a failure here is > > a failure in general so reject device - or it might decide it's up to > > the PSP etc. (userspace can see if it succeeded) > > I'd argue host software can launch this at any time. It will > > be a denial of service attack but so are many other things the host > > can do. > > Trying to visualize it in my head - policy is a kernel cmdline or module > parameter? > > > 2. TDISP policy decision from host (userspace policy control) > > Need to know end goal. > > /sys/bus/pci/devices/0000:11:22.3/tdisp ? > > > 3. IDE opt in from userspace. Policy decision. > > - If not TDISP > > - device_connect(IDE ONLY) - bunch of proxying in host OS. > > - Cert chain and measurements presented to host, host can then check if > > it is happy and expose for next policy decision. > > - Hooks exposed for host to request more measurements, key refresh etc. > > Idea being that the flow is host driven with PSP providing required > > services. If host can just do setup directly that's fine too. > > I'd expect the user to want IDE on from the very beginning, why wait to > turn it on later? The question is rather if the user wants to panic() or > warn() or block the device if IDE setup failed. Right, but when you run out of streams where is the policy to decide who wins. That's why I was thinking lazy IDE when it is explicitly requested > > > - If TDISP (technically you can run tdisp from host, but lets assume > > for now no one wants to do that? (yet)). > > - device_connect(TDISP) - bunch of proxying in host OS. > > - Cert chain and measurements presented to host, host can then check if > > it is happy and expose for next policy decision. > > On AMD SEV TIO the TDISP setup happens in "tdi_bind" when the device is > about to be passed through which is when QEMU (==userspace) starts. > > > > > 4. Flow after this depends on early or late binding (lockdown) > > but could load driver at this point. Userspace policy. > > tdi-bind etc. > > Not sure I follow this. A host or guest driver? > > > >> > >>> 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. > >> > >> 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. > > > > Proxy the CMA messages through the host OS. Doesn't mean host has > > visibility of the keys or certs. So indeed, the actual setup isn't being done > > by the host kernel, but rather by it requesting the 'blob' to send > > to the CMA DOE from PSP. > > > > By my reading that's a bit inelegant but I don't see it being a break > > with the specification. > > > >> > >> 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 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. > > > > Agreed. If can request the PSP does a non TDISP IDE setup then > > I think we are fine. If not then indeed usecases are limited and > > meh, it might be a spec compliance issue but I suspect not as > > TDISP has a note at the top that says: > > > > "Although it is permitted (and generally expected) that TDIs will > > be implemented such that they can be assigned to Legacy VMs, such > > use is not the focus of TDISP." > > > > Which rather implies that devices that don't support other usecases > > are allowed. > > > >> > >> > >>> The next steps: > >>> - expose blobs via configfs (like Dan did configfs-tsm); > >>> - s/tdisp.ko/coco.ko/; q> >>> - 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. > > > > Absolutely agree on this and superficially it feels like this should not > > be hard to hook up. > > True. sysfs it is then. Thanks, > > > > > There will also be paths where a driver wants to see the measurement report > > but that should also be easy enough to enable. > > > > Jonathan > >> > >> Thanks, > >> > >> Lukas > >> > > > > -- > Alexey > >
