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

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 6/29/2023 12:11 PM, Parav Pandit wrote:
> > 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.
It may be fine to _ONLY_ provision virtio configuration through AQ, 
limit the changes in virtio spec.
Actually this is not provisioning a VF, this is modification after 
creation, because we still
create a VF through PCI interface num_vfs.
> 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.
If you want to re-use some transport cmds for SRIOV, that's fine, we 
just can not reuse the whole command set for SRIOV.
For example, we expect AQ as a transport for SIOV, therefore MSIX is 
config-ed through AQ, as we discussed this
set_msix_cmd may not apply to SRIOV for now.

Querying is fine as you know it is read only.
For setting, I assume we need a new mechanism to sycn the PCI config 
space with AQ, and still the host owns the AQ.

> > > > 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.
a hypervisor should not reset anything when the device has been 
passthroughed, or such a hypervisor may be considered buggy
> So such thing does not need special spec level protection.
> An OS driver can handle it internally.
again, I wish we don't introduce more attacking surface even the stack 
is already vulnerable.

Thanks