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: 8254 bytes --]



On 9/20/2023 7:15 PM, Parav Pandit wrote:
>
> Random words like malicious SW to describe an attack do not make sense.
>
this is not random wording, "malicious" used a lot in the papers,
you can search in google scholar
>
> Refer the patches and series and usage model to describe the sw attack 
> if any.
>
> I disagree and I will not repeat all the points anymore.
>
don't only say you disagree, please provide why it is not an attacking 
surface.

The problem still exist:

What if a malicious SW dump guest memory through admin vq LM facility?

I think this is end of this discussion.
>
> If you have comments in [1], please reply in [1].
>
> Series [1] clearly describes the usage model at least for one widely 
> used OS = Linux.
>
> [1] 
> https://lore.kernel.org/virtio-comment/20230909142911.524407-7-parav@nvidia.com/T/#md9fcfa1ba997463de8c7fb8c6d1786b224b0bead
>
> *From:* Zhu, Lingshan <lingshan.zhu@intel.com>
> *Sent:* Wednesday, September 20, 2023 4:41 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 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>
>     <mailto:lingshan.zhu@intel.com>
>     *Sent:* Wednesday, September 20, 2023 3:15 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 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: 23633 bytes --]