From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:48552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ0d4-0003NU-2U for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:08:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YJ0d0-0003Ao-QO for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:08:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:40577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YJ0d0-0003AY-JO for qemu-devel@nongnu.org; Wed, 04 Feb 2015 09:08:26 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t14E8OQT013199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 4 Feb 2015 09:08:25 -0500 Date: Wed, 4 Feb 2015 14:08:20 +0000 From: "Daniel P. Berrange" Message-ID: <20150204140820.GS3032@redhat.com> References: <20150204113229.GN3032@redhat.com> <54D213E0.8090408@redhat.com> <20150204130041.GQ3032@redhat.com> <54D221BC.50008@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <54D221BC.50008@redhat.com> Subject: Re: [Qemu-devel] RFC: Universal encryption on QEMU I/O channels Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org On Wed, Feb 04, 2015 at 02:42:20PM +0100, Paolo Bonzini wrote: > > > On 04/02/2015 14:00, Daniel P. Berrange wrote: > > 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. > > As long as QEMUFile remains there and GIOChannel is used only when > encryption is required, that would be an acceptable limitation. As I > wrote above, migration is a bit special anyway. I'm not sure I'd like the idea of having different codepaths for the encrypted vs non-encrypted impl. it seems like a recipe for increased maintainence work and inconsistent behaviour over the long term. My thought was that QEMUFile would basically go away entirely by the end of the conversion, or at most be dealing with the data rate throttling if that didn't fit nicely into the generic IO layer. > > 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. > > Besides that, QEMU developers are not extremely familiar with all the > glib stuff, and GIOChannel is a thin-enough wrapper that it's pretty > easy to understand what's going on. But that can change if the > alternative has advantages. Perhaps we could start by converting > chardevs from GIOChannel to GIO. > > GIO has TLS bindings (not SASL I think?) in GIO 2.28. Currently we > require glib 2.12 (released 2006) on POSIX systems and glib 2.20 > (released 2009) on Windows. That's very conservative indeed, I wouldn't > mind changing to a newer version. Yeah, it has some level of functionality for TLS, but I'm not sure about the full extent of it and whether it'd be sufficient for what we need in VNC for example. The main difference between GIO's APIs and GIOChannel is that the new GIO stuff is really designed around the idea of asynchronous callbacks for completion of IO. eg g_input_stream_read_async(stream, buffer, size, read_done_callback); and then when read_done_callback gets triggered you have to call g_input_stream_read_finish(stream) in order to get the success/failure status of the read, and the byte count. While it is quite nice for new code IME, this is probably quite alot harder to refit into existing QEMU codebase. So either GIOChannel or something custom that is similar to GIOChannel would likely be an easier fit. > >> 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. > > Yeah, it was only interesting for the GIOChannel boilerplate. 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 :|