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 08:05:24PM +0800, Zhu, Lingshan wrote:
> 
> 
> On 9/20/2023 7:52 PM, Michael S. Tsirkin wrote:
> > 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.
> I agree, although I have to reply because Parav said I am "attacking" AQ
> which is
> not a good wording.
> And I need to show its not attacking, this is discussions on
> LM topics, there may be some debating, and I surely need to provide proof.

I will be very surprised if something costructive comes out of debates
in this style.

Some sure ways to detect flamewars:
- deep thread
- repeating same claims
- ignoring questions/comments

This passes with flying colors and I'm not going to point fingers
but really please start seeing each other's point of view.


> > 
> > > 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.
> Yes this is a denial of service and it can be a problem if the service is a
> critical service
> like a remote attestation server.
> 
> So suspending the VM by admin vq LM commands can attack the system.

um did you read the coco threat model posts? they are educational.
ability to deny service to a VM is currently fundamental to building
PaaS platforms on top of it.


> > 
> > 
> > > 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?
> It tracks dirty pages, may record them in a bitmap.
> 
> Without CoCo, procdump or qemu dump-guest-memory can dump the guest memory
> pages,
> but it does not know which part of memory is guest secrets.
> 
> For example, if a malicious SW wants to sniff the guest networking, the
> bitmap
> of the dirty pages can help to locate the network DMA pages. This also apply
> to disk IOs
> 
> So this enlarges the attacking surface.
> 
> Current live migration solution does not use any PFs tracking dirty pages,
> so no such side channel.


You must be joking. Look into the virtio ring, there are DMA addresses
right there.


> > 
> > > > 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.


---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org