From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NJaYG-0001RX-BP for qemu-devel@nongnu.org; Sat, 12 Dec 2009 17:35:00 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NJaYB-0001MY-BD for qemu-devel@nongnu.org; Sat, 12 Dec 2009 17:34:59 -0500 Received: from [199.232.76.173] (port=56289 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NJaYB-0001MR-8L for qemu-devel@nongnu.org; Sat, 12 Dec 2009 17:34:55 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57526) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NJaYA-0001NV-PX for qemu-devel@nongnu.org; Sat, 12 Dec 2009 17:34:55 -0500 Message-ID: <4B241A99.2000704@redhat.com> Date: Sun, 13 Dec 2009 00:35:05 +0200 From: Dor Laor MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Spice project is now open References: <20091211213911.0dce90dc@redhat.com> <4B22A2D9.6020602@codemonkey.ws> <20091211223250.129675fc@redhat.com> <4B22B035.3010601@codemonkey.ws> <20091211233158.22e6681f@redhat.com> <4B22C093.2090806@codemonkey.ws> <4B231182.1080208@codemonkey.ws> <20091212144433.GA26966@random.random> <4B23B0BE.7080408@codemonkey.ws> <20091212160626.GB26966@random.random> <4B23D585.70400@codemonkey.ws> In-Reply-To: <4B23D585.70400@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: dlaor@redhat.com List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Andrea Arcangeli , Paolo Bonzini , qemu-devel@nongnu.org On 12/12/2009 07:40 PM, Anthony Liguori wrote: > If Spice can crash a guest, that indicates to me that Spice is > maintaining guest visible state. That is difficult architecturally > because if we want to do something like introduce a secure sandbox for > running guest visible emulation, libspice would have to be part of that > sandbox which would seem to be difficult. > > The VNC server cannot crash a guest by comparison. That's not accurate: https://bugzilla.redhat.com/show_bug.cgi?id=505641 - (CVE-2009-3616) CVE-2009-3616 Remote VNC client can cause any QEMU VNC server to crash with a double-free and again: https://bugzilla.redhat.com/show_bug.cgi?id=495646 - Get segfault when changing vnc password Why vnc server code should be protected and spice server not? In addition, like Izik said, the qxl device/driver pair is a must. QXL is a great addition even in 'old' vnc mode since it supports lots of goodies. In addition for caching it also allows s3 state (qxl d3) for the OS, unlike Cirrus. More VNC bugs that we run into: https://bugzilla.redhat.com/show_bug.cgi?id=507880 - qemu hangs during VNC connection from RHEVM https://bugzilla.redhat.com/show_bug.cgi?id=490344 - QEMU: Cannot VNC to a VM if a VNC is already opened to it https://bugzilla.redhat.com/show_bug.cgi?id=497524 - QEMU: Early BIOS error message cannot be seen after reboot in VNC https://bugzilla.redhat.com/show_bug.cgi?id=501263 - KVM: VNC screen is sometimes corrupted (at boot?) If we'll break spice to components we have the following (and I'm not a spice expert): 1. QXL device/driver pair Is anyone debate we should have it in qemu? We should attach it SDL and vnc backend too anyway. 2. VDI (Virtual Desktop Interface) http://www.spice-space.org/vdi.html It's an abstraction layer for graphics/keyboard/mouse/sound /usb/serial. We need it anyway regardless of spice. What is our user like to switch from vnc to SDL on runtime? It's good for usb-over-ip for remoting, for various mouse modes, etc. 3. Spice server Shared library, in the same address space of qemu (like vnc server). Very sophisticated peace of code. 4. Spice client - independent. So #1 shouldn't run into any opposition. We can discuss why #2 is good, the layering separation between guest/host seems good idea to me. As for #3, this is a library. If we have #2, one can even use a separate address space for sanity reasons. From my experience with spice (through all Red Hat QA), 99.9% of failures originated in qemu.. HTH, Dor > > FWIW, I don't see any reason why Spice couldn't be made to be separate > from guest emulation. I think it would just require the right > interfacing in qemu. I think that's purely an implementation detail. > > Regards, > > Anthony Liguori