On Fri, 10 Nov 2023 15:30:57 -0800 Dan Williams <dan.j.williams@xxxxxxxxx> wrote: > Jonathan Cameron wrote: > > On Wed, 1 Nov 2023 08:27:17 +0100 > > Lukas Wunner <lukas@xxxxxxxxx> wrote: > > > > Thanks Alexy, this is a great discussion to kick off. > > > > > 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? > > > Who validates the cert chain, and when? > > > Which slot do you use? > > > Do you return only the cert chain of that single slot or of all slots? > > > Does the PSP read out all measurements available? This may take a while > > > if the measurements are large and there are a lot of them. > > > > I'd definitely like their to be a path for certs and measurement to be > > checked by the Host OS (for the non TDISP path). Whether the > > policy setup cares about result is different question ;) > > > > > > > > > > > > - 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.) > > > > > > > > > > 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. Then the OS can > > > initially authenticate and measure devices and the PSP takes > > > over when needed. > > > > Would that delay mean IDE isn't up - I think that wants to be > > available whether or not pass through is going on. > > > > Given potential restrictions on IDE resources, I'd expect to see an explicit > > opt in from userspace on the host to start that process for a given > > device. (udev rule or similar might kick it off for simple setups). > > > > Would that work for the flows described? > > > > 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 > > 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. > > Are there any platforms that have IDE host capability that are not also > shipping a TSM. I know that some platform allow for either the TSM or > the OS to own that setup, but there are no standards there. I am not > opposed to the native path, but given a cross-vendor "TSM" concept is > needed and that a TSM is likely available on all IDE capable platforms > it seems reasonable for Linux to rely on TSM managed IDE for the near > term if not the long term as well. Just for completeness, (I mentioned it in the LPC discussion): IDE might well be link based between a switch inside the chassis and devices outside the chassis in which case it is all standards defined and the host isn't involved. Not TDISP related though in that case. > > > > > 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. > > 2. TDISP policy decision from host (userspace policy control) > > Need to know end goal. > > If the TSM owns the TDISP state what this policy decision rely comes > down to is IDE stream resource management, I otherwise struggle to > conceptualize "TDISP policy". > > The policy is userspace deciding to assign an interface to a TVM, and > that TVM requests that the assigned interface be allowed to access > private memory. So it's not necessarily TDISP policy, its assigned > interface is allowed to transition to private operation. Agreed - that is probably enough. I was avoiding calling out specific policy method, just don't want it to all flow through in the kernel without a hook. If we assume that we do stuff only when allocated to a TVM then that acts as the gate. > > > 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. > > - 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. > > > > 4. Flow after this depends on early or late binding (lockdown) > > but could load driver at this point. Userspace policy. > > tdi-bind etc. > > It is valid to load the driver and operate the device in shared mode, so > I am not sure that acceptance should gate driver loading. It also seems > like something that could be managed with module policy if someone > wanted to prevent shared operation before acceptance. Indeed that might work. Depends on device and whether it needs to be exposed in shared mode (which may well require driver code auditing etc that can be relaxed if it's up with TDISP and we know it's not a 'fake'). > > [..] > > > > The next steps: > > > > - expose blobs via configfs (like Dan did configfs-tsm); > > I am missing the context here, but for measurements I think those are > better in sysfs. configs was only to allow for multiple containers to grab > attestation reports, measurements are device local and containers can > all see the same measurements. Ah. Fair point. > > > > > - s/tdisp.ko/coco.ko/; > > My bikeshed contribution, perhaps tsm.ko? I am still not someone who can > say "coco" for confidential computing with a straight face. Then definitely should be coco.ko :) Jonathan
