[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state
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 surfaceIt 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 trustedregardless 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 fordiscussion.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 variousindustry 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 todo 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 ofpolling register writes complete in stipulated time. 1) again, they are per-device facilitiesThat 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 frameworkis 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.
Why FLR is a concern to this series? Have you read QEMU live migration code? Does it handle FLR explicitly?2. synchronous registers on the VF cannot inter operate with FLR and device reset flow.
Does it need to handle all PCI attributes?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]