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

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

On 9/19/2023 5:06 PM, Parav Pandit wrote:
>
>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
>> Sent: Tuesday, September 19, 2023 1:32 PM
>>
>> 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.
> In previous email you wrote " As I said before, CC and TDISP is out of spec, that means we should ignore them for now."
> So I am ignoring it now and hence, I am ignoring above comment.
> Lets reach to a common ground for simplified case and than consider more complex cases.
ok
>
>>>> 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?
> For two following reasons.
> 1. All the things needed cannot be communicated over registers efficiently, such as (a) device context, (b) dirty pages.
for a) please read QEMU live migration code.
for b) the registers in config space are control path, we don't store 
dirty pages by the registers.
You can review the next version.
> 2. synchronous registers on the VF cannot inter operate with FLR and device reset flow.
Why FLR is a concern to this series? Have you read QEMU live migration 
code? Does it handle FLR explicitly?
Does it need to handle all PCI attributes?


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org