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

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Sep 20, 2023 at 07:28:39PM +0800, Zhu, Lingshan wrote:
> 
> 
> On 9/20/2023 6:55 PM, Parav Pandit wrote:
> > > From: Michael S. Tsirkin <mst@redhat.com>
> > > Sent: Wednesday, September 20, 2023 4:06 PM
> > > I freely admit the finer points of this extended flamewar have been lost on me,
> > > and I wager I'm not the only one. I thought you wanted to migrate the device
> > > just by accessing the device itself (e.g. the VF) without accessing other devices
> > > (e.g. the PF), while Parav wants it in a separate device so the whole of the
> > > device itself can passed through to guest. Isn't this, fundamentally, the issue?
> > Right. An admin device doing the work of device migration. Today it is the owner PF.
> > In future it can be other admin device who is deleted this task of migration, who can be group owner.
> > All the admin commands that we plumb here just works great in that CC/TDI future, because only thing changes is the admin device issuing this command.
> > 
> > > > the bar is only a proxy, doesn't fix anything. and even larger side
> > > > channel attacking surface: vf-->pf-->vf
> > > In this model there's no pf. BAR belongs to vf itself and you submit commands
> > > for the VF through its BAR.
> > > Just separate from the pci config space.
> > > 
> > > The whole attacking surface discussion is also puzzling.  We either are or are
> > > not discussing confidential computing/TDI.  I couldn't figure it out. This needs a
> > > separate thread I think.
> > True. Many of Lingshan thoughts/comments gets mixed I feel.
> > Because he proposes trap+emulation/mediation-based solution by hypervisor and none of that is secure anyway in CC/TDI concept.
> > He keeps attacking AQ as some side channel attack, while somehow trap+emulation also done by hypervisor is secure, which obviously does not make sense in CC/TDI concept.
> > Both scores equal where hypervisor trust is of concern.
> Please answer directly:

And here you go discussing this in the same thread. I feel you guys are
wasting bytes copying the list with this most people lost track
if not interest.

> What if a malicious SW suspend the guest when it is running through admin vq
> live migration facility

I doubt suspend is a problem - looks like a denial of service to me
and that is not considered part of the threat model at least going by
the documents confidential computing guys are posting on lkml.


> What if a malicious SW dump guest memory by tracking guest dirty pages by
> admin vq live migration faclity

All this does is tell you which pages did device access though.
It looks like on many architectures this information is readily
available anyway due to host page tables being under the hypervisor
control, since this is how it's migrated. Problem? How is memory
migrated otherwise?

> > 
> > And admin command approach [1] has clear direction for CC to delete those admin commands to a dedicated trusted entity instead of hypervisor.
> > 
> > I try to explain these few times, but..
> > 
> > Anyways, if AQ has some comments better to reply in its thread at [1].
> > 
> > [1] https://lore.kernel.org/virtio-comment/20230909142911.524407-7-parav@nvidia.com/T/#md9fcfa1ba997463de8c7fb8c6d1786b224b0bead
> > 
> > I will post v1 for [1] with more mature device context this week along with future provisioning item note.