Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state

Zhu, Lingshan
2023-09-19T08:01:48Z

On 9/19/2023 2:41 AM, Parav Pandit wrote:
>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
>> Sent: Monday, September 18, 2023 3:05 PM
>>
>> On 9/18/2023 2:54 PM, Parav Pandit wrote:
>>>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
>>>> Sent: Monday, September 18, 2023 12:19 PM
>>>> so admin vq based LM solution can be a side channel attacking surface
>>> It will be part of the DSM whenever it will be used in future.
>>> Hence, it is not attack surface.
>> I am not sure, why we have to trust the PF?
>> This is out of virtio scope anyway.
>>
>> I have explained many times how it can be a attack surface, and examples.
>>
> And none of that make any sense as fundamentally, hypervisor is trusted regardless of the approach.
this is not about hypervisors, I am saying admin vq based LM solution
can be a side channel attacking surface
Please refer to my previously listed examples and the TDISP spec is FYI.
>
>> What happen if malicious SW dump guest memory by admin vq dirty page
>> tracking feature?
> What??
> Where is this malicious SW is located, in guest VM?
host, in this attacking model.
>
>>>>>>>> For untrusted hypervisor, same set of attack surface is present
>>>>>>>> with
>>>>>>>> trap+emulation.
>>>>>>>> So both method score same. Hence its not relevant point for discussion.
>>>>>>> this is not hypervisor, Do you see any modern hypervisor have
>>>>>>> these issues?
>>>>>>>
>>>>>>> This is admin vq for LM can be a side channel attacking surface.
>>>>> It is not.
>>>>> Hypervisor is trusted entity.
>>>>> For untrusted hypervisor the TDISP is unified solution build by the
>>>>> various
>>>> industry bodies including DMTF, PCI for last few years.
>>>>> We want to utilize that.
>>>> first, TDISP is out of virtio spec.
>>> Sure, hence, untrusted hypervisor are out of scope.
>>> Otherwise, trap+emulation is equally dead which relies on the hypervisor to
>> do things.
>> so lets focus on LM topic, other than confidential computing.
> ok.
>
>>> Just because data transfer is not done, it does not mean that thousands of
>> polling register writes complete in stipulated time.
>> 1) again, they are per-device facilities
> That does not satisfy that it can somehow do work in < x usec time.
why? Do you mind take examples of basic PCI virtio common config space
registers?
>> 2) we use very few registers, even status byte does not require polling, just re-
>> read with delay.
>>
>> Please refer to the code for setting FEATURES_OK.
> It wont work when one needs to suspend the device.
> There is no point of doing such work over registers as fundamental framework is over the AQ.
why it doesn't work?