qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Yonit Halperin <yhalperi@redhat.com>
Cc: Anthony Liguori <anthony@codemonkey.ws>,
	qemu-devel <qemu-devel@nongnu.org>,
	"spice-devel@freedesktop.org" <spice-devel@freedesktop.org>
Subject: Re: [Qemu-devel] [Spice-devel] seamless migration with spice
Date: Mon, 12 Mar 2012 09:42:01 +0100	[thread overview]
Message-ID: <4F5DB6D9.8060007@redhat.com> (raw)
In-Reply-To: <4F5CA590.1000605@redhat.com>

Hi,

On 03/11/2012 02:16 PM, Yonit Halperin wrote:
> Hi,
>
> We would like to implement seamless migration for Spice, i.e., keeping the currently opened spice client session valid after migration.
> Today, the spice client establishes the connection to the destination before migration starts, and when migration completes, the client's session is moved to the destination, but all the session data is being reset.
>
> We face 2 main challenges when coming to implement seamless migration:
>

<snip (1)>

> (2) In order to restore the source-client spice session in the destination, we need to pass data from the source to the destination.
> Example for such data: in flight copy paste data, in flight usb data
> We want to pass the data from the source spice server to the destination, via Spice client. This introduces a possible race: after migration completes, the source qemu can be killed before the spice-server completes transferring the migration data to the client.

I don't understand why we must transfer this via the client, we should transfer this info using
established qemu migration technologies, and we should transfer it directly from the source
to the dest.

Passing this through the client, means trusting the client which is crazy (from a security pov),
the data passed is not always just data buffers often it contains state info. And transferring
this through the client means opening a whole window of injection vulnerabilities, which can simply
be avoided by sending the data directly.

I know this has been discussed before and I was not involved in that discussion due to -ENOTIME,
sorry about that. But just as the solution for sending the data directly from source to dest proposed
then was nacked by various qemu people, I nack the send the data through the client solution. That
one simply is not acceptable from a security pov. So we must re-think how we can send this data
directly from source to dest, in a way which is acceptable in upstream qemu.

Regards,

Hans

      parent reply	other threads:[~2012-03-12  8:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-11 13:16 [Qemu-devel] seamless migration with spice Yonit Halperin
2012-03-11 14:18 ` Anthony Liguori
2012-03-11 15:25   ` Alon Levy
2012-03-11 15:36     ` Anthony Liguori
2012-03-11 19:11       ` Yonit Halperin
2012-03-12  7:57       ` Gerd Hoffmann
2012-03-12  8:51         ` [Qemu-devel] [Spice-devel] " Hans de Goede
2012-03-12  9:46           ` Gerd Hoffmann
2012-03-12 10:03             ` Alon Levy
2012-03-12 10:26               ` Gerd Hoffmann
2012-03-12 11:29                 ` Alon Levy
2012-03-12 11:34                   ` Gerd Hoffmann
2012-03-12 11:45                     ` Alon Levy
2012-03-12 12:44                       ` Gerd Hoffmann
2012-03-12 14:24                         ` Alon Levy
2012-03-12 14:35                           ` Alon Levy
2012-03-12 11:23             ` Hans de Goede
2012-03-12 12:21               ` Gerd Hoffmann
2012-03-12 12:47             ` Yonit Halperin
2012-03-12 13:50               ` Gerd Hoffmann
2012-03-12 18:45                 ` Yonit Halperin
2012-03-13  6:40                   ` Gerd Hoffmann
2012-03-13  6:52                     ` Yonit Halperin
2012-03-13  7:40                       ` Gerd Hoffmann
2012-03-12 11:39           ` David Jaša
2012-03-12  8:42 ` Hans de Goede [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F5DB6D9.8060007@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=anthony@codemonkey.ws \
    --cc=qemu-devel@nongnu.org \
    --cc=spice-devel@freedesktop.org \
    --cc=yhalperi@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).