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

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

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