virtio — archive

virtio member device provisioning get/set and virtio child device life cycle mixing not needed

From: Lingshan Zhu <[email protected]>
To: [email protected]
Date: Thu, 29 Jun 2023 04:02:00 -0000

On 6/29/2023 10:47 AM, Parav Pandit wrote: >> From: Zhu, Lingshan <[email protected]> >> Sent: Wednesday, June 28, 2023 10:39 PM >> >> >> On 6/29/2023 10:23 AM, Parav Pandit wrote: >>>> From: Zhu, Lingshan <[email protected]> >>>> 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 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.