From: Jan Kiszka <jan.kiszka@siemens.com> To: Wei Wang <wei.w.wang@intel.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org, virtio-comment@lists.oasis-open.org, mst@redhat.com, stefanha@redhat.com, pbonzini@redhat.com Subject: Re: [virtio-comment] [PATCH 5/6 Resend] Vhost-pci RFC: Future Security Enhancement Date: Mon, 30 May 2016 08:23:47 +0200 [thread overview] Message-ID: <574BDC73.7070700@siemens.com> (raw) In-Reply-To: <1464509494-159509-6-git-send-email-wei.w.wang@intel.com> On 2016-05-29 10:11, Wei Wang wrote: > Signed-off-by: Wei Wang <wei.w.wang@intel.com> > --- > FutureWorks | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > create mode 100644 FutureWorks > > diff --git a/FutureWorks b/FutureWorks > new file mode 100644 > index 0000000..210edcd > --- /dev/null > +++ b/FutureWorks > @@ -0,0 +1,21 @@ > +The vhost-pci design is currently suitable for a group of VMs who trust each > +other. To extend it to a more general use case, two security features can be > +added in the future. Sounds a bit like security is just "nice to have" in the foreseen use cases of this mechanism. Is that really true? > + > +1 vIOMMU > +vIOMMU provides the driver VM with the ability to restrict the device VM to > +transiently access a specified portion of its memory. The vhost-pci design > +proposed in this RFC can be extended to access the driver VM's memory with > +vIOMMU. Precisely, the vIOMMU engine in the driver VM configures access > +permissions (R/W) for the vhost-pci device to access its memory. More details > +can be found at https://wiki.opnfv.org/display/kvm/Vm2vm+Mst and > +https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg03993.html Do you have performance estimates on this approach already? One challenge should be how to let the VMs reuse existing buffer mappings so that the vIOMMU isn't continuously reprogrammed - which is likely not very efficient. The other is how to hand over packets/buffers in a chain of multiple VMs. Ideally, there is already a hand-over from sender to the first receiver so that the sender can no longer mess with the packet after the receiver started processing it. However, that will work against efficiency. Essentially, it's the old IPC question of remap vs. copy here. The rest is "just" interfaces to exploit this elegantly. > + > +2 eptp switching > +The idea of eptp swithing allows a vhost-pci device driver to access the mapped > +driver VM's memory in an alternative view, where only a piece of trusted code > +can access the driver VM's memory. More details can be found at > +http://events.linuxfoundation.org/sites/events/files/slides/ > +Jun_Nakajima_NFV_KVM%202015_final.pdf As we learned a while back, this one is not really secure. Any updates on if/how this is going to be fixed? Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
WARNING: multiple messages have this Message-ID (diff)
From: Jan Kiszka <jan.kiszka@siemens.com> To: Wei Wang <wei.w.wang@intel.com>, kvm@vger.kernel.org, qemu-devel@nongnu.org, virtio-comment@lists.oasis-open.org, mst@redhat.com, stefanha@redhat.com, pbonzini@redhat.com Subject: Re: [Qemu-devel] [virtio-comment] [PATCH 5/6 Resend] Vhost-pci RFC: Future Security Enhancement Date: Mon, 30 May 2016 08:23:47 +0200 [thread overview] Message-ID: <574BDC73.7070700@siemens.com> (raw) In-Reply-To: <1464509494-159509-6-git-send-email-wei.w.wang@intel.com> On 2016-05-29 10:11, Wei Wang wrote: > Signed-off-by: Wei Wang <wei.w.wang@intel.com> > --- > FutureWorks | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > create mode 100644 FutureWorks > > diff --git a/FutureWorks b/FutureWorks > new file mode 100644 > index 0000000..210edcd > --- /dev/null > +++ b/FutureWorks > @@ -0,0 +1,21 @@ > +The vhost-pci design is currently suitable for a group of VMs who trust each > +other. To extend it to a more general use case, two security features can be > +added in the future. Sounds a bit like security is just "nice to have" in the foreseen use cases of this mechanism. Is that really true? > + > +1 vIOMMU > +vIOMMU provides the driver VM with the ability to restrict the device VM to > +transiently access a specified portion of its memory. The vhost-pci design > +proposed in this RFC can be extended to access the driver VM's memory with > +vIOMMU. Precisely, the vIOMMU engine in the driver VM configures access > +permissions (R/W) for the vhost-pci device to access its memory. More details > +can be found at https://wiki.opnfv.org/display/kvm/Vm2vm+Mst and > +https://lists.gnu.org/archive/html/qemu-devel/2015-08/msg03993.html Do you have performance estimates on this approach already? One challenge should be how to let the VMs reuse existing buffer mappings so that the vIOMMU isn't continuously reprogrammed - which is likely not very efficient. The other is how to hand over packets/buffers in a chain of multiple VMs. Ideally, there is already a hand-over from sender to the first receiver so that the sender can no longer mess with the packet after the receiver started processing it. However, that will work against efficiency. Essentially, it's the old IPC question of remap vs. copy here. The rest is "just" interfaces to exploit this elegantly. > + > +2 eptp switching > +The idea of eptp swithing allows a vhost-pci device driver to access the mapped > +driver VM's memory in an alternative view, where only a piece of trusted code > +can access the driver VM's memory. More details can be found at > +http://events.linuxfoundation.org/sites/events/files/slides/ > +Jun_Nakajima_NFV_KVM%202015_final.pdf As we learned a while back, this one is not really secure. Any updates on if/how this is going to be fixed? Jan -- Siemens AG, Corporate Technology, CT RDA ITP SES-DE Corporate Competence Center Embedded Linux
next prev parent reply other threads:[~2016-05-30 6:24 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-05-29 8:11 [PATCH 0/6 Resend] *** Vhost-pci RFC *** Wei Wang 2016-05-29 8:11 ` [Qemu-devel] " Wei Wang 2016-05-29 8:11 ` [virtio-comment] [PATCH 1/6 Resend] Vhost-pci RFC: Introduction Wei Wang 2016-05-29 8:11 ` [Qemu-devel] " Wei Wang 2016-05-29 8:11 ` [virtio-comment] [PATCH 2/6 Resend] Vhost-pci RFC: Modification Scope Wei Wang 2016-05-29 8:11 ` [Qemu-devel] " Wei Wang 2016-05-29 8:11 ` [virtio-comment] [PATCH 3/6 Resend] Vhost-pci RFC: Benefits to KVM Wei Wang 2016-05-29 8:11 ` [Qemu-devel] " Wei Wang 2016-05-29 8:11 ` [virtio-comment] [PATCH 4/6 Resend] Vhost-pci RFC: Detailed Description in the Virtio Specification Format Wei Wang 2016-05-29 8:11 ` [Qemu-devel] " Wei Wang 2016-06-01 8:15 ` Xiao Guangrong 2016-06-01 8:15 ` [Qemu-devel] " Xiao Guangrong 2016-06-02 3:15 ` [virtio-comment] " Wang, Wei W 2016-06-02 3:15 ` [Qemu-devel] " Wang, Wei W 2016-06-02 3:52 ` Xiao Guangrong 2016-06-02 3:52 ` [Qemu-devel] " Xiao Guangrong 2016-06-02 8:43 ` [virtio-comment] " Wang, Wei W 2016-06-02 8:43 ` [Qemu-devel] " Wang, Wei W 2016-06-02 11:13 ` Xiao Guangrong 2016-06-02 11:13 ` [Qemu-devel] " Xiao Guangrong 2016-06-03 6:12 ` [virtio-comment] " Wang, Wei W 2016-06-03 6:12 ` [Qemu-devel] " Wang, Wei W 2016-05-29 8:11 ` [virtio-comment] [PATCH 5/6 Resend] Vhost-pci RFC: Future Security Enhancement Wei Wang 2016-05-29 8:11 ` [Qemu-devel] " Wei Wang 2016-05-30 6:23 ` Jan Kiszka [this message] 2016-05-30 6:23 ` [Qemu-devel] [virtio-comment] " Jan Kiszka 2016-05-31 8:00 ` Wang, Wei W 2016-05-31 8:00 ` [Qemu-devel] " Wang, Wei W 2016-06-02 9:27 ` Jan Kiszka 2016-06-02 9:27 ` [Qemu-devel] " Jan Kiszka 2016-06-03 5:54 ` Wang, Wei W 2016-06-03 5:54 ` [Qemu-devel] " Wang, Wei W 2016-05-29 8:11 ` [PATCH 6/6 Resend] Vhost-pci RFC: Experimental Results Wei Wang 2016-05-29 8:11 ` [Qemu-devel] " Wei Wang
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=574BDC73.7070700@siemens.com \ --to=jan.kiszka@siemens.com \ --cc=kvm@vger.kernel.org \ --cc=mst@redhat.com \ --cc=pbonzini@redhat.com \ --cc=qemu-devel@nongnu.org \ --cc=stefanha@redhat.com \ --cc=virtio-comment@lists.oasis-open.org \ --cc=wei.w.wang@intel.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.