[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]