From: Cornelia Huck <cohuck@redhat.com>
To: P J P <ppandit@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
Qemu Developers <qemu-devel@nongnu.org>,
zhangboxian <zhangboxian@huawei.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 1/2] virtio: check VirtQueue Vring object is set
Date: Wed, 29 Nov 2017 12:16:09 +0100 [thread overview]
Message-ID: <20171129121609.61a03d36.cohuck@redhat.com> (raw)
In-Reply-To: <nycvar.YSQ.7.76.1711291445390.12405@wniryva>
On Wed, 29 Nov 2017 15:41:45 +0530 (IST)
P J P <ppandit@redhat.com> wrote:
> Hello Cornelia,
>
> +-- On Tue, 28 Nov 2017, Cornelia Huck wrote --+
> | What is "unfit for use"?
>
> Unfit for use because we see checks like
>
> if (!virtio_queue_get_num(vdev, n)) {
> continue;
> ...
> if (!vdev->vq[n].vring.num) {
> return;
>
> 'virtio_queue_set_rings' sets 'vring.desc' as
>
> vdev->vq[n].vring.desc = desc;
>
> and calls virtio_init_region_cache(vdev, n);
> which returns if vq->vring.desc is zero(0).
>
> addr = vq->vring.desc;
> if (!addr) {
> return;
> }
>
> Same in virtio_queue_set_addr() -> virtio_queue_update_rings().
>
> It seems that for 'vq' instance to be useful, vring.num, vring.desc etc.
> fields need to be set properly. Unless an unused/free 'vq' is being accessed
> to set these fields.
I think the basic problem is still that you conflate two things:
- vring.num, which cannot be flipped between 0 and !0 by the guest
- vring.{desc,avail,used}, which can
IOW, if vring.num == 0, the guest cannot manipulate the queue; if
vring.desc == 0, the guest can.
>
> | I'm not quite sure what you want to achieve with this patch. I assume
> | you want to fix the issue that a guest may provide invalid values for
> | align etc. which can cause qemu to crash or behave badly.
>
> True. In the process I'm trying to figure out if a usable 'vq' instance could
> be decided in once place, than having repeating checks, if possible.
>
> Ex. 'virtio_queue_update_rings' is called as
>
> virtio_queue_set_addr
> -> virtio_queue_update_rings
>
> virtio_queue_set_align
> -> virtio_queue_update_rings
>
> virtio_load
> for (i = 0; i < num; i++) {
> if (vdev->vq[i].vring.desc) {
> ...
> virtio_queue_update_rings
>
> Of these, virtio_load checks that 'vring.desc' is non-zero(0). Current
> patch adds couple checks to the other two callers above. And again,
>
> virtio_queue_update_rings would check
>
> if (!vring->num || !vring->desc || !vring->align) {
> /* not yet setup -> nothing to do */
> return;
> }
vring.num and vring.desc are really different things. You don't want
the guest to do anything with the queue if vring.num == 0, while you
just want to skip various processing if vring.desc == 0.
(virtio_load() does not need to care about vring.num, as it is not
triggered by the guest.)
>
> | If so, you need to do different things for the different points above.
> | - The guest should not muck around with a non-existing queue (num == 0)
> | in any case, so this should be fenced for any manipulation triggered
> | by the guest.
>
> I guess done by !virtio_queue_get_num() check above?
Yes.
>
> | - Processing a non-setup queue (desc == 0; also applies to the other
> | buffers for virtio-1) should be skipped. However, _setting_ desc etc.
> | to 0 from the guest is fine (as long as it follows the other
> | constraints of the spec).
>
> Okay. Though its non-zero(0) value is preferred?
Many functions have a likely/unlikely check, setup routines excepted.
>
> | - Setting alignment to 0 only applies to legacy + virtio-mmio. I would
> | not overengineer fencing this. A simple check in update_rings should
> | be enough.
>
> Okay.x
next prev parent reply other threads:[~2017-11-29 11:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-24 18:34 [Qemu-devel] [PATCH v3 0/2] check VirtiQueue Vring objects P J P
2017-11-24 18:34 ` [Qemu-devel] [PATCH v3 1/2] virtio: check VirtQueue Vring object is set P J P
2017-11-27 10:03 ` Cornelia Huck
2017-11-27 11:15 ` Stefan Hajnoczi
2017-11-27 17:55 ` P J P
2017-11-28 9:11 ` Cornelia Huck
2017-11-28 10:37 ` Stefan Hajnoczi
2017-11-28 11:27 ` P J P
2017-11-28 12:00 ` Cornelia Huck
2017-11-29 10:11 ` P J P
2017-11-29 11:16 ` Cornelia Huck [this message]
2017-11-30 9:16 ` P J P
2017-11-24 18:34 ` [Qemu-devel] [PATCH v3 2/2] tests: add test to check VirtQueue object P J P
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171129121609.61a03d36.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=pbonzini@redhat.com \
--cc=ppandit@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=zhangboxian@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).