On 9/20/2023 6:55 PM, Parav Pandit wrote:
From: Michael S. Tsirkin <m...@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:
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/20230909142911.524407-7-pa...@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-unsubscr...@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-h...@lists.oasis-open.org
