Re: [virtio-dev] Re: [PATCH 0/5] virtio: introduce SUSPEND bit and vq state
"Zhu, Lingshan" <[email protected]>
| Newsgroups | dev.linux.lists.virtio-dev |
|---|---|
| Message-ID | <[email protected]> |
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 <[email protected]> > *Sent:* Wednesday, September 20, 2023 3:15 PM > *To:* Parav Pandit <[email protected]>; Michael S. Tsirkin <[email protected]> > *Cc:* [email protected]; Jason Wang <[email protected]> > *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:*[email protected] > <[email protected]> > <mailto:[email protected]> *On Behalf Of *Zhu, Lingshan > *Sent:* Wednesday, September 20, 2023 12:01 PM > *To:* Parav Pandit <[email protected]> <mailto:[email protected]>; > Michael S. Tsirkin <[email protected]> <mailto:[email protected]> > *Cc:* [email protected]; Jason Wang > <[email protected]> <mailto:[email protected]> > *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<[email protected]> <mailto:[email protected]> > > 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? > > > >