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

On 9/20/2023 6:55 PM, Parav Pandit wrote:
>> From: Michael S. Tsirkin <[email protected]>
>> 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:

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

What if a malicious SW dump guest memory by tracking guest dirty pages 
by admin vq live migration faclity
>
> 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/[email protected]/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: [email protected]
For additional commands, e-mail: [email protected]