> There can be malicious SW on the host, and the host may be hacked and > compromised. > For example: > 1) SUSPEND the a running guest by admin vq > 2) dumping guest memory through admin vq dirty page tracking.
No. hypervisor is trusted entity who is hosting the VM. The device migration is initiated by the hypervisor. I am omitting the TDISP question for now as talked before. TDISP spec will evolve for hypercalls when we get there. From: virtio-dev@lists.oasis-open.org <virtio-dev@lists.oasis-open.org> On Behalf Of Zhu, Lingshan Sent: Wednesday, September 20, 2023 12:01 PM To: Parav Pandit <pa...@nvidia.com>; Michael S. Tsirkin <m...@redhat.com> Cc: virtio-dev@lists.oasis-open.org; Jason Wang <jasow...@redhat.com> Subject: Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state On 9/20/2023 2:08 PM, Parav Pandit wrote: From: Zhu, Lingshan <lingshan....@intel.com><mailto:lingshan....@intel.com> Sent: Wednesday, September 20, 2023 11:36 AM On 9/19/2023 2:49 AM, Michael S. Tsirkin wrote: On Mon, Sep 18, 2023 at 06:41:55PM +0000, Parav Pandit wrote: 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. Well not really. It's over admin commands. When these were built the intent always was that it's possible to use admin commands through another interface, other than admin queue. Is there a problem implementing admin commands over a memory BAR? For example, I can see an "admin command" capability pointing at a BAR where commands are supplied, and using a new group type referring to device itself. I am not sure, if a bar cap would be implemented as a proxy for the admin vq based live migration. then the problems of admin vq LM that we have discussed still exist. the bar is only a proxy, doesn't fix anything. and even larger side channel attacking surface: vf-->pf-->vf AQ LM using PF has no side channel attack as hypervisor and owner device is trusted entity as already discussed. I believe we have discussed this for many times, and I even provide you some examples. Let me repeat for the last time. There can be malicious SW on the host, and the host may be hacked and compromised. For example: 1) SUSPEND the a running guest by admin vq 2) dumping guest memory through admin vq dirty page tracking. These above can happen right? You made TDISP as an example, but have you really read the TDISP spec? In the spec: Device Security Architecture - Administrative interfaces (e.g., a PF) may be used to influence the security properties of the TDI used by the TVM. TEE-I/O requires the device to organize its hardware/software interfaces such that the PF cannot be used to affect the security of a TDI when it is in use by a TVM Clear?
