Re: [Qemu-devel] [virtio-comment] [PATCH 5/6 Resend] Vhost-pci RFC: Future Security Enhancement

[Wang, Wei W]

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 
secure vhost-pci. 
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
> efficient.

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

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 
> if/how
> 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.

Best,
Wei