From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from ws5-mx01.kavi.com (ws5-mx01.kavi.com [34.193.7.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B0222CE79CB for ; Wed, 20 Sep 2023 11:11:33 +0000 (UTC) Received: from lists.oasis-open.org (oasis.ws5.connectedcommunity.org [10.110.1.242]) by ws5-mx01.kavi.com (Postfix) with ESMTP id EB8762AD67 for ; Wed, 20 Sep 2023 11:11:32 +0000 (UTC) Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id B1B5698667C for ; Wed, 20 Sep 2023 11:11:32 +0000 (UTC) Received: from host09.ws5.connectedcommunity.org (host09.ws5.connectedcommunity.org [10.110.1.97]) by lists.oasis-open.org (Postfix) with QMQP id 8C2D3986669; Wed, 20 Sep 2023 11:11:32 +0000 (UTC) Mailing-List: contact virtio-dev-help@lists.oasis-open.org; run by ezmlm List-ID: Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Received: from lists.oasis-open.org (oasis-open.org [10.110.1.242]) by lists.oasis-open.org (Postfix) with ESMTP id 7C65E98666A for ; Wed, 20 Sep 2023 11:11:32 +0000 (UTC) X-Virus-Scanned: amavisd-new at kavi.com X-IronPort-AV: E=McAfee;i="6600,9927,10838"; a="379076370" X-IronPort-AV: E=Sophos;i="6.02,161,1688454000"; d="scan'208,217";a="379076370" X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10838"; a="920244216" X-IronPort-AV: E=Sophos;i="6.02,161,1688454000"; d="scan'208,217";a="920244216" Content-Type: multipart/alternative; boundary="------------Z4VIngHpbxStoL01a8htve5T" Message-ID: Date: Wed, 20 Sep 2023 19:11:25 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Firefox/102.0 Thunderbird/102.15.1 Content-Language: en-US To: Parav Pandit , "Michael S. Tsirkin" Cc: "virtio-dev@lists.oasis-open.org" , Jason Wang References: <67680965-b115-32c7-dfdf-c56ab37bdd81@intel.com> <213a0f94-cee2-d8c5-3c5d-d2d7fc920e75@intel.com> <5f01772f-eb27-bfe0-7f69-b83fbd90dda0@intel.com> <20230918144312-mutt-send-email-mst@kernel.org> <84b2f6b0-c4fb-9b28-53ab-cc8c0b6763c2@intel.com> From: "Zhu, Lingshan" In-Reply-To: Subject: Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state --------------Z4VIngHpbxStoL01a8htve5T Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > *Sent:* Wednesday, September 20, 2023 3:15 PM > *To:* Parav Pandit ; Michael S. Tsirkin > *Cc:* virtio-dev@lists.oasis-open.org; Jason Wang > *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 > > *On Behalf Of *Zhu, Lingshan > *Sent:* Wednesday, September 20, 2023 12:01 PM > *To:* Parav Pandit ; > Michael S. Tsirkin > *Cc:* virtio-dev@lists.oasis-open.org; Jason Wang > > *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 > > 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? > > > > --------------Z4VIngHpbxStoL01a8htve5T Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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> On Behalf Of Zhu, Lingshan
Sent: Wednesday, September 20, 2023 12:01 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 2:08 PM, Parav Pandit wrote:

 
From: Zhu, Lingshan <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?


 

 

 


--------------Z4VIngHpbxStoL01a8htve5T--