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