[Spice-devel] [Qemu-devel] seamless migration with spice

[Yonit Halperin]

On 03/12/2012 11:46 AM, Gerd Hoffmann wrote:
>    Hi,
>
>> The problem with (b) is, that iirc the way b was implemented in the past
>> was still the big blob approach, but then pass the blob through the client,
>> which means an evil client could modify it, causing all sorts of
>> "interesting"
>> behavior inside spice-server. Since we're re-implementing this to me the
>> send a blob through the client approach is simply not acceptable from a
>> security pov, also see my previous mail in this thread.
>
> Agree.  It should be a normal spice message which goes through the spice
> marshaller for parsing&  sanity checking.
>
>> I disagree. Note that there is more info to send over then just which
>> surfaces / images are cached by the client. There also is things like
>> partial complete agent channel messages, including how much bytes must
>> be read
>> to complete the command, etc.
>
> Is there a complete list of the session state we need to save?
>
>> IMHO (b) would only be acceptable if the data send through the client stops
>> becoming a blob.
>
> Using (a) to send a blob isn't better.
>
Gerd/Hans,

Can you explain/exemplify, why sending data as a blob (either by (a) or 
(b)), that is verified only by the two ends that actually use it, is a 
problem?
Lets say the client/qemu are completely aware of the migration data, 
what prevent it from harming it then?

>> Instead the client could simply send a list of all
>> surface ids,
>> etc. which it has cached after it connects to / starts using the new
>> host. Note
>> that the old hosts needs to send nothing for this, this is info the
>> client already
>> has, also removing the need for synchronization.
>
> Yes, some session state is known to the client anyway so we don't need a
> source<->  target channel for them.
>
>> As for certain other
>> data, such
>> as (but not limited to) partially parsed agent messages, these should be
>> send through the regular vmstate methods IMHO.
>
> That isn't easy to handle via vmstate, at least as soon as this goes
> beyond a fixed number of fields aka 'migrate over this struct for me'.
> Think multiple spice clients connected at the same time.
>
>> 1) Do (a), sending everything that way
>> 2) Do (a) sending non client state that way; and
>>     let the client send state like which surfaces it has cached
>>     when the new session starts.
>
> I think we have to look at each piece of state information needed by the
> target and look how to handle this best.
>
> cheers,
>    Gerd
>
> _______________________________________________
> Spice-devel mailing list
> Spice-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/spice-devel