Zhi Wang wrote:
> 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.
This capability needs a definite use case for the kernel to onboard the
complexity, and notifiers in general increase the maintenance burden.
This PCI/TSM proposal is that "connect" can happen independent of any
driver being loaded. If a driver wants to trigger reconnect after it
loads it can, but it is not clear why it would need to get its fingers
into the "connect" process itself. I.e. I would hope that at maximum an
endpoint driver just needs to see the results of "connect", or trigger
reconnect, not intercept the connect flow.
If the connect state is treated like a link state then it is reasonable
to expect that the PCI core restores the link after reset. If that is
the case then the driver's mechanism to trigger reconnect is to call
pci_reset_function() which implicitly handles reconnecting the device.
> 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.
Drivers can already register for ->reset_prepare() and ->reset_done()
notifiers. It would be great to not need to invent new notification
infrastructure, at least without an exceedingly good reason.
> > 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? :)
Probably too early to settle that, we are still trying to figure out how
to log native measurements [1] and the logging mechanism [2]. eBPF only
comes after memcmp() is deemed insufficient, but even memcmp() needs to
plumb the measurements through an attestation mechanism.
[1]: http://lore.kernel.org/r/20240222154529.GA9465@xxxxxxxxx
[2]: http://lore.kernel.org/r/20240128212532.2754325-1-sameo@xxxxxxxxxxxx
