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

Parav Pandit <[email protected]>
Newsgroups dev.linux.lists.virtio-dev
Message-ID <PH0PR12MB5481ABF4B9BC2082BC54AB1DDCFBA@PH0PR12MB5481.namprd12.prod.outlook.com>
> From: Zhu, Lingshan <[email protected]>
> Sent: Monday, September 18, 2023 3:05 PM
> 
> On 9/18/2023 2:54 PM, Parav Pandit wrote:
> >> From: Zhu, Lingshan <[email protected]>
> >> 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.
> I am not sure, why we have to trust the PF?
> This is out of virtio scope anyway.
> 
> I have explained many times how it can be a attack surface, and examples.
> 
And none of that make any sense as fundamentally, hypervisor is trusted regardless of the approach.

> What happen if malicious SW dump guest memory by admin vq dirty page
> tracking feature?
What??
Where is this malicious SW is located, in guest VM?

> >
> >>>>>> For untrusted hypervisor, same set of attack surface is present
> >>>>>> with
> >>>>>> trap+emulation.
> >>>>>> So both method score same. Hence its not relevant point for discussion.
> >>>>> this is not hypervisor, Do you see any modern hypervisor have
> >>>>> these issues?
> >>>>>
> >>>>> This is admin vq for LM can be a side channel attacking surface.
> >>> It is not.
> >>> Hypervisor is trusted entity.
> >>> For untrusted hypervisor the TDISP is unified solution build by the
> >>> various
> >> industry bodies including DMTF, PCI for last few years.
> >>> We want to utilize that.
> >> first, TDISP is out of virtio spec.
> > Sure, hence, untrusted hypervisor are out of scope.
> > Otherwise, trap+emulation is equally dead which relies on the hypervisor to
> do things.
> so lets focus on LM topic, other than confidential computing.
ok.

> > Just because data transfer is not done, it does not mean that thousands of
> polling register writes complete in stipulated time.
> 1) again, they are per-device facilities
That does not satisfy that it can somehow do work in < x usec time.
> 2) we use very few registers, even status byte does not require polling, just re-
> read with delay.
> 
> Please refer to the code for setting FEATURES_OK.
It wont work when one needs to suspend the device.
There is no point of doing such work over registers as fundamental framework is over the AQ.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.