On Wed, Feb 04, 2015 at 01:08:21PM +0000, Dr. David Alan Gilbert wrote: > * Daniel P. Berrange (berra...@redhat.com) wrote: > > In QEMU there are a number of features which involve communication with an > > external system over an I/O channel of some form. The features include > > migration, NBD, VNC and character devices. The I/O channel in question might > > might be a FIFO pipe, a PTY, a TCP socket, a UNIX domain socket, RMDA > > channel > > or something else, while the external system can be another QEMU, libvirt, > > an > > NBD server, or something else. > > > Currently the only place where there is any meaningful level of security is > > the VNC server, which supports the VeNCrypt extension providing TLS sessions > > for data encryption and x509 cert validation for authentication, and the > > SASL > > extension which also provides either encryption of authentication or both. > > The migration data channel is more or less completely unprotected unless it > > is tunnelled via libvirt or equivalent external secure channel. The same is > > true for NBD, though there was a recent discussion about defining an > > extension > > to use TLS. Likewise serial ports, parallel ports, virtio consoles all use > > the > > chardev backends which offer no security features. > > I think fixing this for migration might simplify stuff for users a lot as > well; > the choice of whether libvirt does tunneling or not and what it means > for how block migration happens etc can get very confusing.
Yes, and not helped by the fact that no single current impl offers all desired features - they are all partially overlapping sets :-( > > Since this TLS/SASL code is non-trivial (and obviously security critical), I > > really don't want to end up with 4 separate places to implement it in QEMU. > > IMHO the only practical / sensible approach is to define some kind of > > standard > > I/O channel API internally to QEMU which migration, NBD, chardev and VNC all > > use. That gives us a single place to integrate all the security mechanisms > > we need to support. In libvirt we did something like this a little while > > ago by defining a standard internal sockets API[1], with plugins for things > > like SASL[2], TLS[4] and SSH[5] and it has been very successful in > > simplifying > > the code by centralizing the hairy logic, though I wouldn't aim for exactly > > the same design if doing it again - a more layered approach like QEMU > > blockdev > > drivers is probably better in retrospect. > > > > 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, > > I'm not sure if it makes sense for RDMA; it already has a couple of hooks > that go around the back of QEMUFile in migration, and it's transferring the > data via DMA so the page data doesn't go through the same path. Could you ever anticipate any need for authentication or encryption in the RDMA based channel ? I don't know enough about RDMA myself to know if it makes sense or not, other than the fact that any channel between two separate hosts needs security at some level in the stack. > Some things to keep in mind: > 1) The current patch from Liang Li doing multi threaded compression > It just strikes me as an exmaple of another type of filter in the > migration > stream. Yes, that does make sense in that way, > 2) Postcopy and fault tolerance need a bidirectional channel; and that back > channel tends to be small messages. TLS will require bidirectional channels too in order to perform the handshake. SASL will require bidirectional channels too. So this seems rather inevitable. > 3) I'd considered making a separate socket/fd for passing page data > in the hope of maybe making that page take data via splice; but am not > sure yet. 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 :|
