From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MdhCH-0008Tf-1p for qemu-devel@nongnu.org; Wed, 19 Aug 2009 05:11:09 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MdhCB-0008MR-3l for qemu-devel@nongnu.org; Wed, 19 Aug 2009 05:11:08 -0400 Received: from [199.232.76.173] (port=38826 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MdhCA-0008ML-TF for qemu-devel@nongnu.org; Wed, 19 Aug 2009 05:11:02 -0400 Received: from mail.gmx.net ([213.165.64.20]:46716) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1MdhCA-0004TB-9v for qemu-devel@nongnu.org; Wed, 19 Aug 2009 05:11:02 -0400 Date: Wed, 19 Aug 2009 11:10:59 +0200 From: Reimar =?iso-8859-1?Q?D=F6ffinger?= Subject: Re: [Qemu-devel] Re: [PATCH 5/5] Port apic to new VMState design Message-ID: <20090819091059.GA10336@1und1.de> References: <20090818142405.GA16563@1und1.de> <20090818152112.GA5483@1und1.de> <4A8BB101.9000305@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <4A8BB101.9000305@redhat.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, Aug 19, 2009 at 10:00:01AM +0200, Gerd Hoffmann wrote: > > Basically what I am asking is if you couldn't just add an optional > > callback so some additional stuff can be done after the "basic" state > > has been loaded - or if that isn't desired at least a callback that > > allows verifying the loaded values and aborting execution. > > I think we are going to need post-processing callbacks anyway. Several > drivers have to do some actions after loading the state information. > There you'll be able to set the stats size and also perform sanity > checks on the loaded state. I don't care what they are called, I was just pointing out that the patch was not implementing any of it. And I by now say that e.g. vmware_vga needs it already in the current implementation, it checks for example that the depth of the current display and the one when it was saved match. > > That is completely different from what I meant. > > Changing the RAM compromises the VM and only the VM, an exploit in a > > device emulation might allow to compromise the _host_. Is it now clearer > > what I meant? > > When you are able modify the savevm state you already have access to the > host ... Huh? Being able to modify the savevm state is not the same as being able to run arbitrary code on the host. At least ideally it shouldn't be. Currently there is no way you could even consider running a savevm from an untrusted source, but I think that is just because of qemu's current implementation, not because it has to be.