On 6/29/2023 10:23 AM, Parav Pandit wrote:
>>
From: Zhu, Lingshan <>
>> 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.
