All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Wang <wei.w.wang@intel.com>
To: kvm@vger.kernel.org, qemu-devel@nongnu.org,
	virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, mst@redhat.com,
	stefanha@redhat.com, pbonzini@redhat.com
Cc: Wei Wang <wei.w.wang@intel.com>
Subject: [PATCH 5/6] Vhost-pci RFC: Future Security Enhancement
Date: Sun, 29 May 2016 07:36:34 +0800	[thread overview]
Message-ID: <1464478595-146533-6-git-send-email-wei.w.wang@intel.com> (raw)
In-Reply-To: <1464478595-146533-1-git-send-email-wei.w.wang@intel.com>

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.
+
+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
+
+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
+
+
-- 
1.8.3.1


WARNING: multiple messages have this Message-ID (diff)
From: Wei Wang <wei.w.wang@intel.com>
To: kvm@vger.kernel.org, qemu-devel@nongnu.org,
	virtio-comment@lists.oasis-open.org,
	virtio-dev@lists.oasis-open.org, mst@redhat.com,
	stefanha@redhat.com, pbonzini@redhat.com
Cc: Wei Wang <wei.w.wang@intel.com>
Subject: [Qemu-devel] [PATCH 5/6] Vhost-pci RFC: Future Security Enhancement
Date: Sun, 29 May 2016 07:36:34 +0800	[thread overview]
Message-ID: <1464478595-146533-6-git-send-email-wei.w.wang@intel.com> (raw)
In-Reply-To: <1464478595-146533-1-git-send-email-wei.w.wang@intel.com>

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.
+
+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
+
+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
+
+
-- 
1.8.3.1

  parent reply	other threads:[~2016-05-28 15:40 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-28 23:36 [PATCH 0/6] *** Vhost-pci RFC *** Wei Wang
2016-05-28 23:36 ` [Qemu-devel] " Wei Wang
2016-05-28 23:36 ` [PATCH 1/6] Vhost-pci RFC: Introduction Wei Wang
2016-05-28 23:36   ` [Qemu-devel] " Wei Wang
2016-05-28 23:36 ` [PATCH 2/6] Vhost-pci RFC: Modification Scope Wei Wang
2016-05-28 23:36   ` [Qemu-devel] " Wei Wang
2016-05-28 23:36 ` [PATCH 3/6] Vhost-pci RFC: Benefits to KVM Wei Wang
2016-05-28 23:36   ` [Qemu-devel] " Wei Wang
2016-05-28 23:36 ` [PATCH 4/6] Vhost-pci RFC: Detailed Description in the Virtio Specification Format Wei Wang
2016-05-28 23:36   ` [Qemu-devel] " Wei Wang
2016-05-28 23:36 ` Wei Wang [this message]
2016-05-28 23:36   ` [Qemu-devel] [PATCH 5/6] Vhost-pci RFC: Future Security Enhancement Wei Wang
2016-05-28 23:36 ` [PATCH 6/6] Vhost-pci RFC: Experimental Results Wei Wang
2016-05-28 23:36   ` [Qemu-devel] " Wei Wang
2016-05-31 18:21 ` [Qemu-devel] [PATCH 0/6] *** Vhost-pci RFC *** Eric Blake
2016-06-01  2:15   ` [virtio-comment] " Wang, Wei W
2016-06-01  2:15     ` Wang, Wei W

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=1464478595-146533-6-git-send-email-wei.w.wang@intel.com \
    --to=wei.w.wang@intel.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=virtio-dev@lists.oasis-open.org \
    /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: link
Be 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.