Samuel Ortiz wrote: [..] > > There is always a driver which has to enable the device and tell it where it > > can DMA to/from anyway so the RUN state does not really let the device start > > doing things once it is moved to RUN > > I agree. But setting RUN from the host means that the guest can start > configuring and using that device at any point in time, i.e. even before > any guest component could verify, validate and attest to the TDI. RUN is > precisely defined for that purpose: Telling the TDI that it should now > accept T-bit TLPs, and you want to do that *after* the TVM accepts the > TDI. Here, by having the host move the TDI to RUN, potentially even before > the TVM has even booted, you're not giving the guest a chance to explictly > accept the TDI. I wanted to circle back to this to agree about allowing the guest to control the transition from LOCKED to RUN. Recall the Plumbers conversation where I mentioned TDX moving closer to TIO to streamline the common TSM interface in Linux, and foreshadowing other vendors making similar concessions. This is an example where the "as simple as possible, but no simpler" threshold looks to have been crossed. TDX like COVE allows for guest to trigger LOCKED to RUN transition. For vendor alignment purposes this looks like an opportunity for TIO to enable the same and prevent a vendor-specific semantic difference in the TSM common infrastructure. [..] [inclue Samuel's further justification that I also Ack] > > > After that call, the TDI is usable from a TVM perspective. Before that > > > call it is not, but its configuration and state are locked. > > Right. I still wonder what bad thing can happen if we move to RUN before > > starting the TVM (I suspect there is something), or it is all about > > semantics (for the AMD TIO usecase, at least)? > > It's not only about semantics, it's about ownership. By moving to RUN > before the TVM starts, you're basically saying the host decides if the > TDI is acceptable by the TVM or not. The TVM is responsible for making > that decision and does not trust the host VMM to do so on its behalf, at > least in the confidential computing threat model. > > Is there any specific reason why you wouldn't move the TDI to RUN when > the SEV guest calls into the validat ABI? > > Cheers, > Samuel. >
