virtio — archive

[Lingshan Zhu <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