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

[Stefan Hajnoczi]

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?

signature.asc
Description: PGP signature