From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: [Qemu-devel] Re: [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...] Date: Mon, 02 Nov 2009 21:20:05 +0300 Message-ID: <4AEF22D5.3040702@msgid.tls.msk.ru> References: <1256815818-sup-7805@xpc65.scottt> <1256818566.10825.58.camel@blaa> <4AE9A299.5060003@codemonkey.ws> <1256826351.10825.69.camel@blaa> <4AE9A90F.1060108@codemonkey.ws> <1256827719.10825.75.camel@blaa> <1256830455.25064.155.camel@x200> <1257172722.5075.7.camel@blaa> <4AEEFDCE.1000006@codemonkey.ws> <20091102155228.GB9655@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , Mark McLoughlin , Scott Tsai , kvm , Dustin Kirkland , Rusty Russell , qemu-devel , jdstrand@canonical.com, Marc Deslauriers , kees.cook@canonical.com To: Jamie Lokier Return-path: Received: from isrv.corpit.ru ([81.13.33.159]:48287 "EHLO isrv.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756514AbZKBSUG (ORCPT ); Mon, 2 Nov 2009 13:20:06 -0500 In-Reply-To: <20091102155228.GB9655@shareable.org> Sender: kvm-owner@vger.kernel.org List-ID: Jamie Lokier wrote: > Anthony Liguori wrote: >> Mark McLoughlin wrote: >>>> Canonical's Ubuntu Security Team will be filing a CVE on this issue, >>>> since there is a bit of an attack vector here, and since >>>> qemu-kvm-0.11.0 is generally available as an official release (and now >>>> part of Ubuntu 9.10). >>>> >>>> Guests running linux <= 2.6.25 virtio-net (e.g Ubuntu 8.04 hardy) on >>>> top of qemu-kvm-0.11.0 can be remotely crashed by a non-privileged >>>> network user flooding an open port on the guest. The crash happens in >>>> a manner that abruptly terminates the guest's execution (ie, without >>>> shutting down cleanly). This may affect the guest filesystem's >>>> general happiness. >>>> >>> IMHO, the CVE should be against the 2.6.25 virtio drivers - the bug is >>> in the guest and the issue we're discussing here is just a hacky >>> workaround for the guest bug. >>> >> Yeah, I'm inclined to agree. The guest generates bad data and we exit. >> exit()ing is probably not wonderful but it's a well understood behavior. >> >> The fundamental bug here is in the guest, not in qemu. > > Guests should never be able to crash or terminate qemu, unless they > call something that is intentionally an "exit qemu" hook for the > guest. And even that should be possible to disable. Well, if your buggy NIC driver does something wrong programming the hardware (like the famous r8169 did - it allocated less buffer space than telling to the card, so the card were happily overwriting unrelated kernel memory with content received from network), you will most likely get a machine which does not respond to external events, a stuck machine, until you hit "reset" button (provided there is one) or toggle power. Or just a reboot, depending on what exactly you've hit. If you want kvm to behave like this, wrap it into a trivial shell script that restarts the guest. /mjt From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N51Vq-0001H7-BR for qemu-devel@nongnu.org; Mon, 02 Nov 2009 13:20:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N51Vl-0001Eg-Uj for qemu-devel@nongnu.org; Mon, 02 Nov 2009 13:20:18 -0500 Received: from [199.232.76.173] (port=47915 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N51Vl-0001Ea-Lw for qemu-devel@nongnu.org; Mon, 02 Nov 2009 13:20:13 -0500 Received: from isrv.corpit.ru ([81.13.33.159]:42490) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N51Vj-0005vi-Vv for qemu-devel@nongnu.org; Mon, 02 Nov 2009 13:20:12 -0500 Message-ID: <4AEF22D5.3040702@msgid.tls.msk.ru> Date: Mon, 02 Nov 2009 21:20:05 +0300 From: Michael Tokarev MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH] whitelist host virtio networking features [was Re: qemu-kvm-0.11 regression, crashes on older ...] References: <1256815818-sup-7805@xpc65.scottt> <1256818566.10825.58.camel@blaa> <4AE9A299.5060003@codemonkey.ws> <1256826351.10825.69.camel@blaa> <4AE9A90F.1060108@codemonkey.ws> <1256827719.10825.75.camel@blaa> <1256830455.25064.155.camel@x200> <1257172722.5075.7.camel@blaa> <4AEEFDCE.1000006@codemonkey.ws> <20091102155228.GB9655@shareable.org> In-Reply-To: <20091102155228.GB9655@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Mark McLoughlin , Scott Tsai , kvm , Dustin Kirkland , Rusty Russell , qemu-devel , jdstrand@canonical.com, Marc Deslauriers , kees.cook@canonical.com Jamie Lokier wrote: > Anthony Liguori wrote: >> Mark McLoughlin wrote: >>>> Canonical's Ubuntu Security Team will be filing a CVE on this issue, >>>> since there is a bit of an attack vector here, and since >>>> qemu-kvm-0.11.0 is generally available as an official release (and now >>>> part of Ubuntu 9.10). >>>> >>>> Guests running linux <= 2.6.25 virtio-net (e.g Ubuntu 8.04 hardy) on >>>> top of qemu-kvm-0.11.0 can be remotely crashed by a non-privileged >>>> network user flooding an open port on the guest. The crash happens in >>>> a manner that abruptly terminates the guest's execution (ie, without >>>> shutting down cleanly). This may affect the guest filesystem's >>>> general happiness. >>>> >>> IMHO, the CVE should be against the 2.6.25 virtio drivers - the bug is >>> in the guest and the issue we're discussing here is just a hacky >>> workaround for the guest bug. >>> >> Yeah, I'm inclined to agree. The guest generates bad data and we exit. >> exit()ing is probably not wonderful but it's a well understood behavior. >> >> The fundamental bug here is in the guest, not in qemu. > > Guests should never be able to crash or terminate qemu, unless they > call something that is intentionally an "exit qemu" hook for the > guest. And even that should be possible to disable. Well, if your buggy NIC driver does something wrong programming the hardware (like the famous r8169 did - it allocated less buffer space than telling to the card, so the card were happily overwriting unrelated kernel memory with content received from network), you will most likely get a machine which does not respond to external events, a stuck machine, until you hit "reset" button (provided there is one) or toggle power. Or just a reboot, depending on what exactly you've hit. If you want kvm to behave like this, wrap it into a trivial shell script that restarts the guest. /mjt