Re: [PATCH v5 5/8] libvduse: Add VDUSE (vDPA Device in Userspace) library

[Yongji Xie]

On Wed, May 18, 2022 at 9:46 PM Stefan Hajnoczi <stefanha@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