Hi,
On 06/10/2012 04:44 PM, Alon Levy wrote:
<snip>
Obligatory migration data:
-------------------------
(1) agent/spicevmc/smartcard write buffer. i.e., data that reached the server
after savevm, and thus was not written to the device.
Currently, spicevmc and smartcard do not have write buffer, but since buffers
can reach the server after savevm, they should have one. I'm not sure if even
today they should attempt to write to the guest if it is stopped. The agent
code also can write to the guest even if it is stopped; I think it is a bug.
(2) agent/smartcard partial data that had been read from the device and wasn't
sent to the client since its reading hasn't completed.
Currently we don't have such data for spicevmc, because we push to the client
any amount of data we read. In the future we might want to control the rate and
the size of data we send/receive, and then we will have outgoing buffer.
I'm still not a big fan of the concept of server data going through the client,
this means the server
will need to seriously sanity check what it receives to avoid potentially new
attacks on it.
I'm wondering why not do the following:
1) spicevmc device gets a savevm call, tell spice-server to send a message to
the client telling it
to stop sending more data to *this* server.
2) client sends an ack in response to the stop sending data server
3) server waits for ack.
4) savevm continues only after ack, which means all data which was in flight
has been received.
Have you seen the qemu-devel thread Yonit referred to in the beginning?
Let me quote:
"
Spice is *not* getting a hook in migration where it gets to add
arbitrary amounts of downtime to the migration traffic. That's a
terrible idea.
"
Hmm, bummer, I still believe a solution like the one I outlined would have been
both better
and *simpler*. But alas, looks like we really need to do this the hard way
then...
That still leaves this worry though:
(c) As for security issues, I don't think that it should raise a problem since
the client is trusted by both the src and the target.
The client is trusted to access the *vm*, not the *host*, and this allows
attacks on spice-server,
which is running on the *host*.
Which means we need to be very very careful, and preferably use this mechanism
as little as possible.
Regards,
Hans
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
