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