[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [virtio-dev] Backend libraries for VirtIO device emulation
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:
pgpVc6twFRZ2J.pgp
Description: OpenPGP digital signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]