qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels
Date: Wed, 4 Feb 2015 13:00:41 +0000
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Feb 04, 2015 at 01:43:12PM +0100, Paolo Bonzini wrote:
> 
> 
> On 04/02/2015 12:32, Daniel P. Berrange wrote:
> > So my idea would be that we define a QEMUChannel object and set of APIs to
> > standardize all interaction with sockets, pipes, RDMA, whatever $channel,
> > and then convert the QEMU features I've mentioned over to use that. I think
> > that would be simpler than trying to untangle QEMUFile code from migration
> > and then extend its features.
> 
> Could it be GIOChannel simply?
> 
> 1) Chardev is already mostly a wrapper around GIOChannel
> 
> 2) NBD and VNC could be converted to GIOChannel with relative ease
> 
> 3) migration is more complicated because (unlike everything else) it
> uses a separate thread and blocking sockets, but you could probably
> write a GIOChannel-based implementation of QEMUFile.

It might be possible to base it on GIOChannel, but IIRC some of the
migration code was using iovecs for I/O and GIOChannel API doesn't
allow for that. So you'd have to sacrifice performance by issuing a
separate syscall for each iovec element which seems sucky to me.
If you think that's an acceptable limitation though, I could certainly
explore use of GIOChannel.

More broadly speaking GIOChannel has fallen out of favour in the
glib ecosystem, with most apps/libraries more focused on use of
the GIO APIs instead, but IIUC QEMU avoids use of the GIO library
due to need to support older glib versions.

> I found a GIOChannel wrapper for gnutls at
> https://github.com/aldebaran/connman/blob/master/gweb/giognutls.c.  It's
> not the right license for QEMU (GPLv2-only) but it's only 400 lines of
> code.  If necessary I can help with clean-room reverse engineering.

It doesn't seem todo any thing related to certificate validation which
explains why it is so short compared ot the gnutls code we already have
for VNC in QEMU. So I don't think it's particularly useful in terms of
saving effort.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

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