OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[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 9/20/2023 8:05 PM, 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.
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.
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.

supplementary comments for my own reply:

Confidential computing is still out of the spec, and I think we should focus
on current solution
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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]