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

["Zhu, Lingshan" <lingshan.zhu@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 6402 bytes --]

On 9/20/2023 5:52 PM, Parav Pandit wrote:
>
> Hi Lingshan,
>
> Last two email replies in non-next format are getting hard to follow.
>
> Can you please revert back to have text-based emails?
>
> When one wants to use PF for the live migration in trusted hypervisor, 
> PF is in the trust zone.
>
even without live migration, it can be an attacking surface while guest 
running.
As repeated for many times, it can be used by malicious SW to dump guest 
memory
>
> In future when hypervisor is not trusted, the task of LM will be 
> delegated to other infrastructure TVM.
>
> Ravi at Intel already explained this a year ago using migration TD.
>
> This fits very well without bifurcating the member device which is 
> extremely hard.
>
TD, TDX or TDX-IO are more complex topics, and we should
focus on our live migration solution, not CC.

My point is: using bar cap as a proxy for admin vq based LM is still 
problematic.

Maybe we can close this.
>
> Parav
>
> *From:* Zhu, Lingshan <lingshan.zhu@intel.com>
> *Sent:* Wednesday, September 20, 2023 3:15 PM
> *To:* Parav Pandit <parav@nvidia.com>; Michael S. Tsirkin <mst@redhat.com>
> *Cc:* virtio-dev@lists.oasis-open.org; Jason Wang <jasowang@redhat.com>
> *Subject:* Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND 
> bit and vq state
>
> On 9/20/2023 4:34 PM, Parav Pandit wrote:
>
>     @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2
>     4;}@font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2
>     4;}@font-face {font-family:Consolas; panose-1:2 11 6 9 2 2 4 3 2
>     4;}p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in;
>     font-size:11.0pt; font-family:"Calibri",sans-serif;}a:link,
>     span.MsoHyperlink {mso-style-priority:99; color:blue;
>     text-decoration:underline;}pre {mso-style-priority:99;
>     mso-style-link:"HTML Preformatted Char"; margin:0in;
>     margin-bottom:.0001pt; font-size:10.0pt; font-family:"Courier
>     New";}span.HTMLPreformattedChar {mso-style-name:"HTML Preformatted
>     Char"; mso-style-priority:99; mso-style-link:"HTML Preformatted";
>     font-family:Consolas;}span.fontstyle0
>     {mso-style-name:fontstyle0;}span.EmailStyle21
>     {mso-style-type:personal-reply; font-family:"Calibri",sans-serif;
>     color:windowtext;}.MsoChpDefault {mso-style-type:export-only;
>     font-size:10.0pt; mso-ligatures:none;}div.WordSection1
>     {page:WordSection1;}
>
>     > There can be malicious SW on the host, and the host may be hacked
>     and compromised.
>     > For example:
>     > 1) SUSPEND the a running guest by admin vq
>     > 2) dumping guest memory through admin vq dirty page tracking.
>
>
>     No. hypervisor is trusted entity who is hosting the VM.
>
> The PF may not owned by the hypervisor and the host can be hacked and 
> computerized.
>
>     The device migration is initiated by the hypervisor.
>
>     I am omitting the TDISP question for now as talked before.
>
>     TDISP spec will evolve for hypercalls when we get there.
>
> Confidential computing is out of the spec, as we discussed and agreed.
>
> This is to demonstrate why even using a bar cap as proxy for admin vq 
> LM is still problematic.
> TDISP gives examples of the attacking models, and admin vq based LM
> conforms to the models.
>
>     *From:*virtio-dev@lists.oasis-open.org
>     <virtio-dev@lists.oasis-open.org>
>     <mailto:virtio-dev@lists.oasis-open.org> *On Behalf Of *Zhu, Lingshan
>     *Sent:* Wednesday, September 20, 2023 12:01 PM
>     *To:* Parav Pandit <parav@nvidia.com> <mailto:parav@nvidia.com>;
>     Michael S. Tsirkin <mst@redhat.com> <mailto:mst@redhat.com>
>     *Cc:* virtio-dev@lists.oasis-open.org; Jason Wang
>     <jasowang@redhat.com> <mailto:jasowang@redhat.com>
>     *Subject:* Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce
>     SUSPEND bit and vq state
>
>     On 9/20/2023 2:08 PM, Parav Pandit wrote:
>
>           
>
>             From: Zhu, Lingshan<lingshan.zhu@intel.com>  <mailto:lingshan.zhu@intel.com>
>
>             Sent: Wednesday, September 20, 2023 11:36 AM
>
>               
>
>             On 9/19/2023 2:49 AM, Michael S. Tsirkin wrote:
>
>                 On Mon, Sep 18, 2023 at 06:41:55PM +0000, Parav Pandit wrote:
>
>                         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.
>
>                 Well not really. It's over admin commands. When these were built the
>
>                 intent always was that it's possible to use admin commands through
>
>                 another interface, other than admin queue. Is there a problem
>
>                 implementing admin commands over a memory BAR? For example, I can see
>
>                 an "admin command" capability pointing at a BAR where commands are
>
>                 supplied, and using a new group type referring to device itself.
>
>             I am not sure, if a bar cap would be implemented as a proxy for the admin vq
>
>             based live migration. then the problems of admin vq LM that we have discussed
>
>             still exist. the bar is only a proxy, doesn't fix anything. and even larger side
>
>             channel attacking surface: vf-->pf-->vf
>
>           
>
>         AQ LM using PF has no side channel attack as hypervisor and owner device is trusted entity as already discussed.
>
>     I believe we have discussed this for many times, and I even
>     provide you some examples.
>
>     Let me repeat for the last time.
>
>     There can be malicious SW on the host, and the host may be hacked
>     and compromised.
>     For example:
>     1) SUSPEND the a running guest by admin vq
>     2) dumping guest memory through admin vq dirty page tracking.
>
>     These above can happen right?
>
>     You made TDISP as an example, but have you really read the TDISP spec?
>     In the spec:
>
>     Device Security Architecture - Administrative interfaces (e.g., a
>     PF) may be
>     used to influence the security properties of the TDI used by the TVM.
>
>     TEE-I/O requires the device to organize its hardware/software
>     interfaces such that the PF cannot
>     be used to affect the security of a TDI when it is in use by a TVM
>
>     Clear?
>
>
>           
>

[-- Attachment #2: Type: text/html, Size: 17970 bytes --]