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

Zhu, Lingshan
2023-09-19T08:05:31Z

On 9/19/2023 3:53 PM, Parav Pandit wrote:
>> 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?
You said:"Lingshan wanted to take this TDISP extension in future."

How do you conclude this statement? Did I ever said I want to take TDISP
extension in future?