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 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. I 
still think we should resolve the issues first.