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 02:39:00 -0000

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