[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [virtio-comment] [PATCH 5/6 Resend] Vhost-pci RFC: Futu
Wang, Wei W
Re: [Qemu-devel] [virtio-comment] [PATCH 5/6 Resend] Vhost-pci RFC: Future Security Enhancement
Tue, 31 May 2016 08:00:19 +0000
On Mon 5/30/2016 2:24 PM, Jan Kiszka Wrote:
> On 2016-05-29 10:11, Wei Wang wrote:
> > Signed-off-by: Wei Wang <address@hidden>
> > ---
> > 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?
Not really. It's usually a tradeoff between performance and security, so I
think having security doesn't always mean "Nice" :-)
Instead of proposing a compromised solution, we can actually offer two
independent solutions, performance oriented vhost-pci (let's call it fast
vhost-pci) and security oriented vhost-pci (say, secure vhost-pci). It's up to
the users to choose which one to use according to their use cases. So, the
secured version of vhost-pci can be viewed as another option for users (not a
replacement of this proposal).
Here is a use example:
There are two groups of VMs running on the same host machine. The frequent
inter-VM communication between VMs in Group A can choose the fast vhost-pci
mechanism. In a special case that a VM from Group A needs to communicate with a
VM from Group B, they should set up a new NIC each and specify the use of the
Since the secure vhost-pci is on our future plan, the traditional vhost-user
can be an option for that inter-Group communication currently.
> > +
> > +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
I think one option here is to reserve a large block of GPA area (like a memory
pool). The buffers are allocated from and freed to the pool.
Another one would be using batching. For example, set up a batch of 32 buffers
(just give the starting guest physical address, and the 32 buffers are
guest-physically continuous) each time.
> The other is how to hand over packets/buffers in a chain of multiple VMs.
> there is already a hand-over from sender to the first receiver so that the
> 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
> interfaces to exploit this elegantly.
There are several ways to do a remapping. The remapping we are using here is to
have the entire driver VM's memory mapped by the device VM, that is, the driver
VM's memory is completely shared with the device VM.
If I understand that old remapping based IPC problem correctly, this kind of
remapping requires a high degree of coordination between the two parts (i.e.
the device VM and the driver VM). I think "virtq" is right the coordination
mechanism here - the device VM grabs and fills a buffer from the available ring
and puts the filled buffer to the used ring, so I don't think the sender would
mess with the packet after the receiver started to process it.
Please point out if I didn't get your point correctly. Thanks.
> > +
> > +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
> this is going to be fixed?
Right, that is why we claimed it as a protection mechanism. However, one option
we are trying is to fix the related holes from the hardware. We can give
updates once it's ready.
- [Qemu-devel] [PATCH 0/6 Resend] *** Vhost-pci RFC ***, Wei Wang, 2016/05/28
- [Qemu-devel] [PATCH 1/6 Resend] Vhost-pci RFC: Introduction, Wei Wang, 2016/05/28
- [Qemu-devel] [PATCH 2/6 Resend] Vhost-pci RFC: Modification Scope, Wei Wang, 2016/05/28
- [Qemu-devel] [PATCH 5/6 Resend] Vhost-pci RFC: Future Security Enhancement, Wei Wang, 2016/05/28
- [Qemu-devel] [PATCH 4/6 Resend] Vhost-pci RFC: Detailed Description in the Virtio Specification Format, Wei Wang, 2016/05/28
- [Qemu-devel] [PATCH 3/6 Resend] Vhost-pci RFC: Benefits to KVM, Wei Wang, 2016/05/28
- [Qemu-devel] [PATCH 6/6 Resend] Vhost-pci RFC: Experimental Results, Wei Wang, 2016/05/28