Zhi Wang wrote: [..] > Hey Dan, > > 1) What is the expectation of using the device connect and disconnect > in the guest-driven secure I/O enlightenment? "Connect" is state of the link that can be automatically maintained over events like reset and error recovery. The guest is responsible for Bind / Unbind. Now, the host can optionally "Connect" in response to a "Bind" event, but it is not clear that such a mechanism is needed. It likely is going to depend on how error handling is implemented, and whether an event that causes disconnect can be recovered. We may get there, but likely not in the initial phases of the implementation. > In the last device security meeting, you said the sysfs interface was > mostly for higher level software stacks, like virt-manager. I was > wondering what would be the picture looks like when coping these > statement with the guest-driven model. Are we expecting the device > connect triggered by QEMU when extracting the guest request from the > secure channel in this case? I think it is simplest for now if "Connect" is a pre-requisite for guest-triggered "Bind". > 2) How does the device-specific logic fit into the new TSM > services? E.g. when the TDISP connect is triggered by userspace, a > device needs to perform quirks before/after/inside the verbs, or a > device needs an interface to tell TSM service when it is able to > response to some verbs. Do you think we needs to have a set of > callbacks from the device side for the PCI TSM service to call? True "quirks" would be driven by bug reports. Outside of that likely the attestation information needs to have multiple validation entry points for userspace, PCI core, and endpoint drivers to each have a chance to deploy some attestation policy. Some of these questions will need have common answers developed between the native CMA implementation and the TSM implementation since CMA needs to solve some of ABI issues of making measurements available to attestation agents. At Plumbers I had been thinking "golden measurements" injected into the kernel ahead of interface validation gives the kernel the most autonomy, but questions about measurement nonce and other concerns tempered my thinking there. Plenty to still talk about and navigate.
