OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[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


> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Monday, September 18, 2023 3:05 PM
> 
> On 9/18/2023 2:54 PM, Parav Pandit 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.
> 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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]