[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160720123017.GA5682@danjae.aot.lge.com>
Date: Wed, 20 Jul 2016 21:30:17 +0900
From: Namhyung Kim <namhyung@...nel.org>
To: Stefan Hajnoczi <stefanha@...il.com>
Cc: LKML <linux-kernel@...r.kernel.org>,
Paolo Bonzini <pbonzini@...hat.com>,
Radim Kr??m???? <rkrcmar@...hat.com>,
"Michael S. Tsirkin" <mst@...hat.com>,
Anthony Liguori <aliguori@...zon.com>,
Anton Vorontsov <anton@...msg.org>,
Colin Cross <ccross@...roid.com>,
Kees Cook <keescook@...omium.org>,
Tony Luck <tony.luck@...el.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ingo Molnar <mingo@...nel.org>,
Minchan Kim <minchan@...nel.org>, kvm@...r.kernel.org,
qemu-devel@...gnu.org, virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH 2/3] qemu: Implement virtio-pstore device
On Wed, Jul 20, 2016 at 09:21:08AM +0100, Stefan Hajnoczi wrote:
> On Wed, Jul 20, 2016 at 12:48:39AM +0900, Namhyung Kim wrote:
> > Hello,
> >
> > On Mon, Jul 18, 2016 at 11:03:53AM +0100, Stefan Hajnoczi wrote:
> > > On Mon, Jul 18, 2016 at 01:37:40PM +0900, Namhyung Kim wrote:
> > > > +static void virtio_pstore_handle_io(VirtIODevice *vdev, VirtQueue *vq)
> > > > +{
> > > > + VirtIOPstore *s = VIRTIO_PSTORE(vdev);
> > > > + VirtQueueElement *elem;
> > > > + struct virtio_pstore_hdr *hdr;
> > > > + ssize_t len;
> > > > +
> > > > + for (;;) {
> > > > + elem = virtqueue_pop(vq, sizeof(VirtQueueElement));
> > > > + if (!elem) {
> > > > + return;
> > > > + }
> > > > +
> > > > + hdr = elem->out_sg[0].iov_base;
> > > > + if (elem->out_sg[0].iov_len != sizeof(*hdr)) {
> > > > + error_report("invalid header size: %u",
> > > > + (unsigned)elem->out_sg[0].iov_len);
> > > > + exit(1);
> > > > + }
> > >
> > > Please use iov_to_buf() instead of directly accessing out_sg[]. Virtio
> > > devices are not supposed to assume a particular iovec layout. In other
> > > words, virtio_pstore_hdr could be split across multiple out_sg[] iovecs.
> > >
> > > You must also copy in data (similar to Linux syscall implementations) to
> > > prevent the guest from modifying data while the command is processed.
> > > Such race conditions could lead to security bugs.
> >
> > By accessing elem->out_sg[0].iov_base directly, I abused it as an
> > in-and-out buffer. But it seems not allowed by the virtio spec, do I
> > have to use separate buffers for request and response?
>
> Yes, a virtqueue element has (host read-only) out buffers followed by
> (host write-only) in buffers.
Thanks for clarification. I'll split them.
Thanks,
Namhyung
Powered by blists - more mailing lists