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

On 9/20/2023 8:05 PM, Zhu, Lingshan wrote:
>
>
> On 9/20/2023 7:52 PM, Michael S. Tsirkin wrote:
>> On Wed, Sep 20, 2023 at 07:28:39PM +0800, Zhu, Lingshan wrote:
>>>
>>> On 9/20/2023 6:55 PM, Parav Pandit wrote:
>>>>> From: Michael S. Tsirkin <[email protected]>
>>>>> 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:
>> And here you go discussing this in the same thread. I feel you guys are
>> wasting bytes copying the list with this most people lost track
>> if not interest.
> I agree, although I have to reply because Parav said I am "attacking" 
> AQ which is
> not a good wording.
>
> And I need to show its not attacking, this is discussions on
> LM topics, there may be some debating, and I surely need to provide 
> proof.
>>
>>> What if a malicious SW suspend the guest when it is running through 
>>> admin vq
>>> live migration facility
>> I doubt suspend is a problem - looks like a denial of service to me
>> and that is not considered part of the threat model at least going by
>> the documents confidential computing guys are posting on lkml.
> Yes this is a denial of service and it can be a problem if the service 
> is a critical service
> like a remote attestation server.
>
> So suspending the VM by admin vq LM commands can attack the system.
>>
>>
>>> What if a malicious SW dump guest memory by tracking guest dirty 
>>> pages by
>>> admin vq live migration faclity
>> All this does is tell you which pages did device access though.
>> It looks like on many architectures this information is readily
>> available anyway due to host page tables being under the hypervisor
>> control, since this is how it's migrated. Problem? How is memory
>> migrated otherwise?
> It tracks dirty pages, may record them in a bitmap.
>
> Without CoCo, procdump or qemu dump-guest-memory can dump the guest 
> memory pages,
> but it does not know which part of memory is guest secrets.
>
> For example, if a malicious SW wants to sniff the guest networking, 
> the bitmap
> of the dirty pages can help to locate the network DMA pages. This also 
> apply
> to disk IOs
>
> So this enlarges the attacking surface.
>
> Current live migration solution does not use any PFs tracking dirty 
> pages,
> so no such side channel.
supplementary comments for my own reply:

Confidential computing is still out of the spec, and I think we should focus
on current solution

>>
>>>> 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/[email protected]/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: [email protected]
> For additional commands, e-mail: [email protected]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]