From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=54311 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1PR4jT-0003ew-QO
	for qemu-devel@nongnu.org; Fri, 10 Dec 2010 10:18:05 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PR4jR-0008DI-Ut
	for qemu-devel@nongnu.org; Fri, 10 Dec 2010 10:18:03 -0500
Received: from mail.codesourcery.com ([38.113.113.100]:54713)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <paul@codesourcery.com>) id 1PR4jR-0008Cx-MZ
	for qemu-devel@nongnu.org; Fri, 10 Dec 2010 10:18:01 -0500
From: Paul Brook <paul@codesourcery.com>
Date: Fri, 10 Dec 2010 15:17:58 +0000
References: <cover.1291987020.git.amit.shah@redhat.com>
	<201012101359.50252.paul@codesourcery.com>
	<20101210145906.GC15015@amit-x200.redhat.com>
In-Reply-To: <20101210145906.GC15015@amit-x200.redhat.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201012101517.59050.paul@codesourcery.com>
Subject: [Qemu-devel] Re: [PATCH 5/5] virtio-serial: Error out if guest
	sends unexpected vq elements
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Amit Shah <amit.shah@redhat.com>
Cc: qemu list <qemu-devel@nongnu.org>

> On (Fri) Dec 10 2010 [13:59:50], Paul Brook wrote:
> > > Check if the guest really sent any items in the out_vq before using
> > > them.  Similarly, check if there is a buffer to send data in before
> > > writing.
> > 
> > Can this actually happen? If so why/how?
> > Why does it need a special case in this device?
> 
> A malicious guest (ie, a guest with the virtio_console module suitably
> modified) could send in buffers with the 'input' bit set instead of
> output as expected or vice-versa.

So what? Who cares if they get it wrong?

It's entirely unclear whether this is actually an error. If a request has zero 
size then we just transfer zero bytes, exactly as requested.

Even if you accept this should be a diagnosable error, I suspect your patch is 
still insufficient. I don't see any code to check that input queue requests 
have zero output segments, nor do I see anything to handle zero-length 
segments.

> > If this is guest triggerable then calling abort() is wrong.
> 
> It's either a guest bug or a malicious guest.  What action is
> recommended?

Killing the whole VM in response to a malformed request to a device is clearly 
a bug in that device.  You should report an error to the guest in the normal 
manner.  IIRC virtio lacks any consistent error reporting mechanisms, and the 
usual response when asked to do something impossible is to reset the device.

Paul