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

Zhu, Lingshan
2023-09-20T09:45:05Z

[-- Attachment #1: Type: text/plain, Size: 3610 bytes --]

On 9/20/2023 4:34 PM, Parav Pandit wrote:
>
> > 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 PF may not owned by the hypervisor and the host can be hacked and
computerized.
>
> 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.
>
Confidential computing is out of the spec, as we discussed and agreed.

This is to demonstrate why even using a bar cap as proxy for admin vq LM
is still problematic.
TDISP gives examples of the attacking models, and admin vq based LM
conforms to the models.
>
> *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 <parav@nvidia.com>; Michael S. Tsirkin <mst@redhat.com>
> *Cc:* virtio-dev@lists.oasis-open.org; Jason Wang <jasowang@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.zhu@intel.com> <mailto:lingshan.zhu@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?
>

[-- Attachment #2: Type: text/html, Size: 10996 bytes --]