On Mon, 26 Feb 2024 22:34:54 -0800
Dan Williams <dan.j.williams@xxxxxxxxx> wrote:
> 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".
>
Thanks so much for the reply.
IIUC, it means a guest assumes the device is in "connect" state when
noticing a TDI, and it has the awareness that the "connect" state will
be taken care by host until it needs to step in error recovery?
I am more thinking of how device driver talks with the PCI core.
+static int pci_tsm_connect(struct pci_dev *pdev)
+{
+ struct pci_tsm_req *req __free(req_free) = NULL;
+
+ /* opportunistic state checks to skip allocating a request */
+ if (pdev->tsm->state >= PCI_TSM_CONNECT)
+ return 0;
+
As this patch is triggered by userspace through sysfs, I am wondering
would it be a good idea to let the device driver step in around the
device connect/disconnect flow in the future? as a device might needs to
be switched to different states before it is ready to handle SPDM and
IDE.
Maybe the PCI core (pci_tsm_{connect, disconnect, error_handling}())
should broadcast the event through a notifier when checking the connect
state. An example kernel user of that notifier can forward the event to
the userspace as udev events via PF_NETLINK.
+ req = tsm_ops->req_alloc(pdev, PCI_TSM_OP_CONNECT);
+ if (!req)
+ return -ENOMEM;
+
+ scoped_cond_guard(mutex_intr, return -EINTR, tsm_ops->lock) {
+ enum pci_tsm_op_status status;
+
+ /* revalidate state */
+ if (pdev->tsm->state >= PCI_TSM_CONNECT)
+ return 0;
+ if (pdev->tsm->state < PCI_TSM_INIT)
+ return -ENXIO;
+
+ do {
+ status = tsm_ops->exec(pdev, req);
+ req->seq++;
+ } while (status == PCI_TSM_SPDM_REQ);
+
+ if (status == PCI_TSM_FAIL)
+ return -EIO;
+ pdev->tsm->state = PCI_TSM_CONNECT;
+ }
+ return 0;
+}
> > 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
Yup, I was just thinking another approach for the device specific code
to step in for pci_tsm_{connect,disconnect}() without a driver and
pci-quirks just popped up. :)
> 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.
Yes. We had been discussing that a lot. :) I also carefully watched the
playback of LPC Confidential MC, quite a lot nice discussions. Out
of curiosity, were folks think eBPF a good fit or an overkill here? :)
Thanks,
Zhi.
