Re: [libvirt] [RFC][PATCH]: Secure migration
On Mon, Mar 16, 2009 at 04:26:58PM +0100, Chris Lalancette wrote:
All,
Attached is a *very* rough first draft of the secure migration code I'm
working on. This is in no way ready for merge. That being said, this
demonstrates the basic idea that I'm pursuing, and I've actually been able to
perform a KVM secure live migrate using this. Before I go and finish polishing
it up, though, I wanted to make sure there wasn't anything fundamentally wrong
with the approach. So, in that vein, comments are appreciated.
diff --git a/qemud/remote_protocol.h b/qemud/remote_protocol.h
index 75def5e..d97a18b 100644
--- a/qemud/remote_protocol.h
+++ b/qemud/remote_protocol.h
@@ -41,6 +41,8 @@ typedef remote_nonnull_string *remote_string;
#define REMOTE_SECURITY_MODEL_MAX VIR_SECURITY_MODEL_BUFLEN
#define REMOTE_SECURITY_LABEL_MAX VIR_SECURITY_LABEL_BUFLEN
#define REMOTE_SECURITY_DOI_MAX VIR_SECURITY_DOI_BUFLEN
+#define REMOTE_CONNECT_SECURE_MIGRATION_DATA_MAX 65536
+#define REMOTE_CONNECT_SECURE_MIGRATION_COOKIE_MAX 65536
typedef char remote_uuid[VIR_UUID_BUFLEN];
Okay I have tried to think again about this, from the code fragment
before and discussions on IRC while performances are tolerable, there
is a lot of costs related to the 64KB chunking imposed by the XML-RPC.
It is probably acceptable for a class of users who really want
encryption of their data but I would like to make sure we don't close
the door for a possibly more performant implementation.
Trying to reopen a bit the discussion we had before on opening a
separate encrypted connection, this would have a number of potential
improvements over the XML-RPC:
- no chunking, far less context-switching (it would be good to know
how much of excess time spent in the secure migration is data
encoding, how much is overall system burden)
- seems to me a more standard encrypted TCP/IP connection would be
more likely to be able to reuse crypto hardware if/when they get
available.
My main concern is keeping a port open in the firewall for the
incoming connection of the encrypted data, and I wonder if it's really
necessary, basically since the receiver and the sender can both
communicate already via the XML-RPC maybe something like STUN (for UDP)
where both end open simultaneously a new connection to the other side
might work, and that can be coordinated via the XML-RPC (passing the new
port opened etc). The point being that usually firewall block only
incoming connections to non-registered port but outcoming connections
are allowed to go, I have no idea if this can be made to work though.
In general I would like to make sure we have room in the initial phase
to add such a negociation where an optimal solution may be attempted,
possibly falling back to a normal XML-RPC solution like this.
Basically, make sure we can try to be as efficient as possible, and
allow the protocol to evolve, but fallback to XML-RPC encapsulation
if that initial round fails.
any though ?
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/