[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state
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 surfaceIt 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 corehypervisor 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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]