RE: [virtio-comment] Re: virtio member device provisioning get/set and virtio child device life cycle mixing not needed

[Parav Pandit <parav@nvidia.com>]

> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Thursday, June 29, 2023 12:02 AM
> 
> On 6/29/2023 10:47 AM, Parav Pandit wrote:
> >> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >> Sent: Wednesday, June 28, 2023 10:39 PM
> >>
> >>
> >> On 6/29/2023 10:23 AM, Parav Pandit wrote:
> >>>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >>>> Sent: Wednesday, June 28, 2023 10:18 PM
> >>>>> So msix provisioning via AQ is fine. VF can expose new MSIX
> >>>>> capability post
> >>>> reconfiguration via AQ.
> >>>> It is the guest to config MSIX of an assigned VF by writing to MSIX
> capability.
> >>>> However host owns the AQ, means host can modify the MSIX config
> >>>> even when guest operational running.
> >>> Host can do many things not just MSIX config.
> >>> Host is not supposed modify the config.
> >>>
> >>> In some OS MSI-X actual values are not even written by the guest...
> >> yest, current host stack is not perfect.
> >> So lets resolve these issues first rather than introduce new attack surface.
> >>>> A new synchronization mechanism? Trap accesses to MSIX cap? Ban
> >>>> access of MSIX through AQ after DRIVER_OK?
> >>>> Do you have any detailed information about how to prevent the
> >>>> conflicts like this?
> >>> A hypervisor is a trusted entity to not mess with the VF.
> >>> A hypervisor can go to an extreme to even do PCI FLR while guest is
> running..
> >>>
> >>> So no need to go to the extreme.
> >>>
> >>> When hypervisor is untrusted in relatively far future, when a VF is
> >>> put in some
> >> secure enclave and locked hypervisor will not such access.
> >>> At that point large part will be covered.
> >> There can be other malicious software and a hypervisor may compromise.
> > In any case it is not the role of the AQ etc to provide such protection etc.
> Yes, it is not AQ's responsibility. I wish we don't introduce more weakness.
> >
> > Safeguarding from hypervisor is completely different topic using confidential
> computing, TDISP and other affiliated standards.
> > It is far beyond msix config piece to tackle.
> >
> > Before we reach there, virtio spec has certain fundamental catch up to be
> done, at least to me.
> So lets work on that first than rush into the AQ/VF provisioning case.
> >
I mean querying and provisioning feature bits and config space fields is the basic functionality before attempting to securing it.
I was told that you are going to rebase the tvq series on top of AQ, hence the ask to split the series to two.
If I misunderstood, its fine, my bad.
Someone else will pick up the features/config provisioning+query part.

> >> I still think we should resolve the issues first.
> > I donât think this is really an issue.
> > Passthrough VF devices are already there for more than a decade and msix
> config is just one small piece of it to provision, among others.
> passthrough, like vfio which assign the device including its config space to a
> guest, works well. While AQ is a side channel.
Sure. AQ is side channel but hypervisor's ability to access VF while in use including doing FLR and more is already exist.
So such thing does not need special spec level protection.
An OS driver can handle it internally.