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

[Parav Pandit <parav@nvidia.com>]

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

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.