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

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

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


Subject: RE: [virtio-comment] Re: virtio member device provisioning get/set and virtio child device life cycle mixing not needed


> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> Sent: Wednesday, June 28, 2023 10:39 PM
> 
> 
> On 6/29/2023 10:23 AM, Parav Pandit wrote:
> >> From: Zhu, Lingshan <lingshan.zhu@intel.com>
> >> Sent: Wednesday, June 28, 2023 10:18 PM
> >
> >>> So msix provisioning via AQ is fine. VF can expose new MSIX
> >>> capability post
> >> reconfiguration via AQ.
> >> It is the guest to config MSIX of an assigned VF by writing to MSIX capability.
> >> However host owns the AQ, means host can modify the MSIX config even
> >> when guest operational running.
> > Host can do many things not just MSIX config.
> > Host is not supposed modify the config.
> >
> > In some OS MSI-X actual values are not even written by the guest...
> yest, current host stack is not perfect.
> So lets resolve these issues first rather than introduce new attack surface.
> >
> >> A new synchronization mechanism? Trap accesses to MSIX cap? Ban
> >> access of MSIX through AQ after DRIVER_OK?
> >> Do you have any detailed information about how to prevent the
> >> conflicts like this?
> > A hypervisor is a trusted entity to not mess with the VF.
> > A hypervisor can go to an extreme to even do PCI FLR while guest is running..
> >
> > So no need to go to the extreme.
> >
> > When hypervisor is untrusted in relatively far future, when a VF is put in some
> secure enclave and locked hypervisor will not such access.
> > At that point large part will be covered.
> There can be other malicious software and a hypervisor may compromise. 

In any case it is not the role of the AQ etc to provide such protection etc.

Safeguarding from hypervisor is completely different topic using confidential computing, TDISP and other affiliated standards.
It is far beyond msix config piece to tackle.

Before we reach there, virtio spec has certain fundamental catch up to be done, at least to me.

> I still think we should resolve the issues first.
I donât think this is really an issue.
Passthrough VF devices are already there for more than a decade and msix config is just one small piece of it to provision, among others.


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