qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [PATCH 5/5] Port apic to new VMState design


From: Reimar Döffinger
Subject: Re: [Qemu-devel] Re: [PATCH 5/5] Port apic to new VMState design
Date: Wed, 19 Aug 2009 11:10:59 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]