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

Parav Pandit
2023-09-19T07:53:16Z

> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Tuesday, September 19, 2023 1:16 PM
>
> On 9/19/2023 3:32 PM, Parav Pandit wrote:
> >> From: Jason Wang <jasowang@redhat.com>
> >> Sent: Tuesday, September 19, 2023 9:58 AM
> >>
> >> On Mon, Sep 18, 2023 at 2:55 PM Parav Pandit <parav@nvidia.com> wrote:
> >>>> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >>>> Sent: Monday, September 18, 2023 12:19 PM
> >>>
> >>>> so admin vq based LM solution can be a side channel attacking
> >>>> surface
> >>> It will be part of the DSM whenever it will be used in future.
> >>> Hence, it is not attack surface.
> >> DSM is not a part of TVM. So it really depends on what kind of work
> >> did the admin virtqueue do. For commands that can't be self-contained
> >> like provisioning, it is fine, since it is done before the TDI
> >> assignment. But it not necessarily for your migration proposal. It
> >> seems you've found another case that self-containing is important:
> >> allowing the owner to access the member after TDI is attached to TVM
> >> is a side channel attack.
> > TVM and DSM specs will be extended in future when we get there, so core
> hypervisor will not be involved.
> > With trap+mediation, it is involved.
> >
> > Lingshan wanted to take this TDISP extension in future.
> > So are you both aligned or not yet?
> I didn't say that, never ever.

In your previous email you wrote,

1. "so lets focus on LM topic, other than confidential computing."
2. "again, TDISP is out of spec and TDISP devices are not migratable."

From above two comments from you I understood it that way, you want to focus now on the LM _other_than_ CC.
How to read it differently?