On Wed, May 18, 2022 at 9:46 PM Stefan Hajnoczi <stefa...@redhat.com> wrote:
>
> On Wed, May 04, 2022 at 03:40:48PM +0800, Xie Yongji wrote:
> > +static int vduse_queue_update_vring(VduseVirtq *vq, uint64_t desc_addr,
> > + uint64_t avail_addr, uint64_t
> > used_addr)
> > +{
> > + struct VduseDev *dev = vq->dev;
> > + uint64_t len;
> > +
> > + len = sizeof(struct vring_desc);
> > + vq->vring.desc = iova_to_va(dev, &len, desc_addr);
> > + assert(len == sizeof(struct vring_desc));
> > +
> > + len = sizeof(struct vring_avail);
> > + vq->vring.avail = iova_to_va(dev, &len, avail_addr);
> > + assert(len == sizeof(struct vring_avail));
> > +
> > + len = sizeof(struct vring_used);
> > + vq->vring.used = iova_to_va(dev, &len, used_addr);
> > + assert(len == sizeof(struct vring_used));
>
> Can these assertions be triggered by a malicious virtio driver? For
> example, if a guest is accessing this device, will the vDPA/VDUSE kernel
> code forward the address to QEMU without validation?
>
> If yes, then it's necessary to return an error here instead of aborting.
> A qemu-storage-daemon process might contain multiple VDUSE exports and
> an error in one export shouldn't kill the entire process.
>
> I haven't audited the code, but this is a general issue: if vDPA/VDUSE
> kernel code forwards untrusted inputs to us then we cannot abort or
> crash. Usually the kernel is trusted by userspace but maybe not in this
> case since it may just forward inputs from a malicious VIRTIO driver?
Make sense. And it can also be triggered by the malicious VM in
vhost-vdpa cases. Will fix it in v6.
Thanks,
Yongji
