Re: [PATCH 05/11] PCI/TSM: Authenticate devices via platform TSM

[Xu Yilun <yilun.xu@linux.intel.com>]

> >> >> For the current CCA implementation bind is equivalent to VDEV_CREATE
> >> >> which doesn't mark the device LOCKED. Marking the device LOCKED is
> >> >> driven by the guest as shown in the steps below.
> >> >
> >> > Could you elaborate why vdev create & LOCK can't be done at the same
> >> > time, when guest requests "lock"? Intel TDX also requires firmware calls
> >> > like tdi_create(alloc metadata) & tdi_bind(do LOCK), but I don't see
> >> > there is need to break them out in different phases.
> >> >
> >>
> >> Yes, that is possible and might be what I will end up doing. Right now
> >> I have kept the interface flexible enough as I am writing these changes.
> >
> > Good to know that, thanks.
> >
> >> Device can possibly be presented in locked state to the guest.
> >
> > This is also what I did before. But finally I dropped (or pending) this
> > "early binding" support. There are several reset operations during VM
> > setup and booting, especially the ones in bios. They breaks LOCK state
> > and I have to make VFIO suppress the reset, or reset & recover, but that
> > seems not worth the effort.
> >
> > May wanna know how you see this problem.
> 
> Currently, my approach involves a split vdev_create and a TDISP lock, which is
> why I haven't encountered the issue mentioned above. The current changes
> implement vdev_create via the VMM, while the guest makes an RSI call to
> switch the device to the locked state.
> 
> I chose to separate vdev_create and TDISP lock into two distinct steps
> to simplify the process and better align it with the RMM spec [1].
> 
> I noticed that SEV-TIO performs a KVM_EXIT_VMGEXIT, which carries out a
> similar operation unless it has already been handled during VM startup.
> From your reply above, I understand there was a proposal to combine
> VDEV_CREATE and TDISP_LOCK. However, you also mentioned that if we
> present the device in a locked state to a VM early in the boot process,
> we might unintentionally break the TDISP lock state.

That doesn't break the proposal to combine VDEV CREATE & LOCK. We end up
make VMM do nothing about Secure at VM boot, just normal shared passthrough.
VMM does VDEV create & LOCK in a batch when guest asks for bind (or lock
or connect, or whatever verb).

I think if any device specific thing must be done *between* VDEV CREATE
and LOCK, then they must be separated. But I haven't found yet.

Thanks,
Yilun

> 
> I will look up the previous discussions to better understand the
> rationale behind combining vdev_create and lock.
> 
> [1] https://developer.arm.com/-/cdn-downloads/permalink/Architectures/Armv9/DEN0137_1.1-alp12.zip
> 
> -aneesh