Re: [virtio-dev] Backend libraries for VirtIO device emulation

[Halil Pasic <pasic@linux.ibm.com>]

[-- Attachment #1: Type: text/plain, Size: 1958 bytes --]

On Wed, 11 Mar 2020 17:24:11 +0000
Stefan Hajnoczi <stefanha@redhat.com> wrote:

> > I thought so - but does any vhost-user implementation assume it has
> > access to the entire of the guests memory space? I can see why that
> > might be seen as undesirable from a security point of view.  
> 

On s390 we do assume we have access to the whole guest memory
space if VIRTIO_F_ACCESS_PLATFORM is not set.

> VMMs typically give the vhost-user device program access to the entirety
> of guest RAM.  That's because unmodified VIRTIO guest drivers typically
> require access to all of guest memory.
> 
> If the guest software cooperates then it's possible to reduce the shared
> memory region.  In other words, the vhost-user protocol doesn't demand
> that guest RAM is shared, it just requires all addresses to be within
> the shared memory region, whatever that may be.

In that case, I guess, we would have to negotiate
VIRTIO_F_ACCESS_PLATFORM. vhost-user already has support for
VIRTIO_F_ACCESS_PLATFORM, but in context of vhost-user it means: do
IOVA translation. Translation is basically boils down to IOMMU/IOTLB
support, and the specs (docs/interop/vhost-user.rst) says that the
translated stuff needs to be within a region set via
VHOST_USER_SET_MEM_TABLE.

I'm wondering how restricting the memory region shared vhost-user program
should work, unless we impose restrictions on what physical addresses
may be used for virtio buffers (regardless of whether what lands in the
virtqueue is an IOVA or a GPA), and make everybody in the stack aware of
this.

Of course sharing the whole guest memory space with the vhost-user
program does not necessarily mean the guest can actually access the
whole guest memory. For example memory encryption or other means of
protecting memory (e.g. s390 protected VMs) may ensure that the
vhost-user program can not mess with anything that in is not supposed to.

Regards,
Halil

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]