From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=55007 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PR4vX-0004CF-Tv for qemu-devel@nongnu.org; Fri, 10 Dec 2010 10:30:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PR4vW-00039K-7Q for qemu-devel@nongnu.org; Fri, 10 Dec 2010 10:30:31 -0500 Received: from mx1.redhat.com ([209.132.183.28]:13802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PR4vV-000398-VF for qemu-devel@nongnu.org; Fri, 10 Dec 2010 10:30:30 -0500 Date: Fri, 10 Dec 2010 21:00:16 +0530 From: Amit Shah Message-ID: <20101210153015.GF15015@amit-x200.redhat.com> References: <201012101359.50252.paul@codesourcery.com> <20101210145906.GC15015@amit-x200.redhat.com> <201012101517.59050.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <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: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paul Brook Cc: qemu list On (Fri) Dec 10 2010 [15:17:58], Paul Brook wrote: > > 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? Just let the error_report() be there and continue as if nothing happened? > 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. virtio actually supports sending both, input as well as output types of buffers in one go. > > > 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. OK, agreed. Amit