qemu-devel
[Top][All Lists]
Advanced

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

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


From: Yonit Halperin
Subject: Re: [Qemu-devel] [Spice-devel] seamless migration with spice
Date: Mon, 12 Mar 2012 14:47:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

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
address@hidden
http://lists.freedesktop.org/mailman/listinfo/spice-devel




reply via email to

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