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

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

[-- 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 --]