Re: [Qemu-devel] [RFC 0/2] virtio-vhost-user: add virtio-vhost-user device

[Stefan Hajnoczi]

On Mon, Jan 22, 2018 at 10:04:18PM +0200, Michael S. Tsirkin wrote:
> On Mon, Jan 22, 2018 at 12:17:51PM +0000, Stefan Hajnoczi wrote:
> > On Mon, Jan 22, 2018 at 11:33:46AM +0800, Jason Wang wrote:
> > > On 2018年01月19日 21:06, Stefan Hajnoczi wrote:
> > > > These patches implement the virtio-vhost-user device design that I have
> > > > described here:
> > > > https://stefanha.github.io/virtio/vhost-user-slave.html#x1-2830007
> > > 
> > > Thanks for the patches, looks rather interesting and similar to split 
> > > device
> > > model used by Xen.
> > > 
> > > > 
> > > > The goal is to let the guest act as the vhost device backend for other 
> > > > guests.
> > > > This allows virtual networking and storage appliances to run inside 
> > > > guests.
> > > 
> > > So the question still, what kind of protocol do you want to run on top? If
> > > it was ethernet based, virtio-net work pretty well and it can even do
> > > migration.
> > > 
> > > > This device is particularly interesting for poll mode drivers where 
> > > > exitless
> > > > VM-to-VM communication is possible, completely bypassing the hypervisor 
> > > > in the
> > > > data path.
> > > 
> > > It's better to clarify the reason of hypervisor bypassing. (performance,
> > > security or scalability).
> > 
> > Performance - yes, definitely.  Exitless VM-to-VM is the fastest
> > possible way to communicate between VMs.  Today it can only be done
> > using ivshmem.  This patch series allows virtio devices to take
> > advantage of it and will encourage people to use virtio instead of
> > non-standard ivshmem devices.
> > 
> > Security - I don't think this feature is a security improvement.  It
> > reduces isolation because VM1 has full shared memory access to VM2.  In
> > fact, this is a reason for users to consider carefully whether they
> > even want to use this feature.
> 
> True without an IOMMU, however using a vIOMMU within VM2
> can protect the VM2, can't it?
[...]
> > Yes, this is the big weakness of vhost-user in general.  The IOMMU
> > feature doesn't offer good isolation
> 
> I think that's an implementation issue, not a protocol issue.

The IOMMU feature in the vhost-user protocol adds address translation
and permissions but the underlying memory region file descriptors still
expose all of guest RAM.

An implementation that offers true isolation has to enforce the IOMMU
state on the shared memory (e.g. read & write access).

> > and even when it does, performance
> > will be an issue.
> 
> If the IOMMU mappings are dynamic - but they are mostly
> static with e.g. dpdk, right?

Excellent idea!  My understanding is that DPDK's memory area for mbufs
is static.

The question is whether this area contains only packet payload buffers?
Then it would be feasible to map only this memory (plus vrings) and
achieve isolation.

If other data is intermingled with the packet payload buffers then it's
difficult to guarantee security since an evil VM can modify the
non-payload data to trigger race conditions, out-of-bounds memory
accesses, and other bugs.

Anyway, what you've suggested sounds like the most realistic option for
achieving isolation without losing performance.

> > > >   * Implement the VRING_KICK eventfd - currently vhost-user slaves must 
> > > > be poll
> > > >     mode drivers.
> > > >   * Optimize VRING_CALL doorbell with ioeventfd to avoid QEMU exit.
> > > 
> > > The performance implication needs to be measured. It looks to me both kick
> > > and call will introduce more latency form the point of guest.
> > 
> > I described the irqfd + ioeventfd approach above.  It should be faster
> > than virtio-net + bridge today.
> > 
> > > >   * vhost-user log feature
> > > >   * UUID config field for stable device identification regardless of PCI
> > > >     bus addresses.
> > > >   * vhost-user IOMMU and SLAVE_REQ_FD feature
> > > 
> > > So an assumption is the VM that implements vhost backends should be at 
> > > least
> > > as secure as vhost-user backend process on host. Could we have this
> > > conclusion?
> > 
> > Yes.
> > 
> > Sadly the vhost-user IOMMU protocol feature does not provide isolation.
> > At the moment IOMMU is basically a layer of indirection (mapping) but
> > the vhost-user backend process still has full access to guest RAM :(.
> 
> An important feature would be to do the isolation in the qemu.
> So trust the qemu running VM2 but not VM2 itself.

I think what you suggested above about DPDK's static mappings is even
better.  It does not require trusting VM2's QEMU.  It's also simpler
than implementing isolation in QEMU.

signature.asc
Description: PGP signature