Migration TLS support
Migration TLS support
The migration I/O transport code has been enhanced to allow the use of TLS to provide both data encryption and authentication via x509 certificates. This provides protection for the guest memory and device state against modification or snooping by network based attackers while migration is taking place. It also prevents compromise by rogue clients beating the source QEMU in connecting to the target host.
[x] Changes to QEMU
[x] Affects all archs
Benefits to QEMU and upper layers
- libvirt is able to provide secure migration transport to management applications like OpenStack, without needing to inefficiently tunnel the migration data stream over the libvirtd connection.
- The state of user's VM are protected from adversaries attacking the network over which the migration is taking place.
Added / removed / deprecated / changed settings exposed to higher layers or users
- The 'info migrate' (HMP) and 'query-migrate' (QMP) commands gained an extra field "error description" when their status is "failed". This provides a description of what caused the failure to facilitate debugging (eg DNS lookup failed, remote host was not listening on port, TLS certificates failed validation, etc).
(qemu) info migrate capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off x-postcopy-ram: off Migration status: failed total time: 0 milliseconds error description: Certificate does not match the hostname localhost
- The "migrate_set_parameter" (HMP), "migrate-set-parameters" (QMP) and "query-migrate-parameters" (QMP) methods all gain two new parameters. The 'tls-creds' parameter is used to provide the ID of a 'tls-creds' object instance that contains the TLS credentials to use for the connection. Setting this parameter turns on the use of TLS for the migration channel. The 'tls-hostname' parameter is used to override the default hostname used during validation of the x509 certificate. This is useful when the TCP URI being connected to refers to a different hostname than the target host will report in its certificate. Usually this will not be required.
How to test the feature
On the target host, QEMU would be launched with a set of TLS credentials for a server endpoint
$ qemu-system-x86_64 -monitor stdio -incoming defer \ -object tls-creds-x509,dir=/home/berrange/security/qemutls,endpoint=server,id=tls0 \ ...other args...
To enable incoming TLS migration 2 monitor commands are then used
(qemu) migrate_set_str_parameter tls-creds tls0 (qemu) migrate_incoming tcp:myhostname:9000
On the source host, QEMU is launched in a similar manner but using client endpoint credentials
$ qemu-system-x86_64 -monitor stdio \ -object tls-creds-x509,dir=/home/berrange/security/qemutls,endpoint=client,id=tls0 \ ...other args...
To enable outgoing TLS migration 2 monitor commands are then used
(qemu) migrate_set_str_parameter tls-creds tls0 (qemu) migrate tcp:otherhostname:9000
List of commits
12992c16d9afd8a23a94a84ad532a1adedf9e511 migration: remove qemu_get_fd method from QEMUFile 11808bb0c422134bf09119f4aa22c59b0ce84bf3 migration: remove support for non-iovec based write handlers e122636562218b3d442cd2cd18fbc188dd9ce709 migration: add support for encrypting data with TLS 69ef1f36b0f882fc5ba9491fb272fa5f83ac1d3d migration: define 'tls-creds' and 'tls-hostname' migration parameters 2594f56d4c7ef621da5d0c21921f8fda32025623 migration: don't use an array for storing migrate parameters a24939f2791d930f109ddb2658147aa4eae40361 migration: move definition of struct QEMUFile back into qemu-file.c 7fdc61c75d4064d2e48777172bbe8e0e970de7d9 migration: delete QEMUFile stdio implementation 40946ae40b33b8aa03fa9b56a374f5d4b5f7aab7 migration: delete QEMUFile sockets implementation 2a22b4f3703e1e3daf448841966a01a9d1a3f4ae migration: delete QEMUSizedBuffer struct 8b7c5c0f525561ac081d49363863799f11eb3113 migration: delete QEMUFile buffer implementation 8925839f00cd2d9fd96066154098db476140b715 migration: convert savevm to use QIOChannel for writing to files 6ddd2d76ca6f86f7a6c29291ec3bca32d15bab24 migration: convert RDMA to use QIOChannel interface 527792fae60486c912146a14f601b830d160fe36 migration: convert exec socket protocol to use QIOChannel 64802ee57f68a2aedcdf06b8d4a65daa6d894e3a migration: convert fd socket protocol to use QIOChannel e65c67e4dad18a1f04be426f23cc4d64a32c7548 migration: convert tcp socket protocol to use QIOChannel 6f860ae75566e858593d2c067909a6d1e9feccbf migration: rename unix.c to socket.c d984464eb9e7ebc10e65469b0b7158556489ac96 migration: convert unix socket protocol to use QIOChannel 61b67d473d2471d5b470cd4653947ddaaa2c1c44 migration: convert post-copy to use QIOChannelBuffer d59ce6f34434bf47a9b26138c908650bf9a24be1 migration: add reporting of errors for outgoing migration 48f07489edc1c9b10f21781c850e99e0cde97545 migration: add helpers for creating QEMUFile from a QIOChannel a9cfeb33bb23a8104eeeac5769165476cbf13fe3 migration: introduce a new QEMUFile impl based on QIOChannel 9e4d2b98ee98f4cee50d671e500eceeefa751ee0 migration: force QEMUFile to blocking mode for outgoing migration 06ad513532b1a6085abf4a5dab15d1a4719f715c migration: introduce set_blocking function in QEMUFileOps 0436e09f9654dfa6f7439531bf443b1f78870ed6 migration: split migration hooks out of QEMUFileOps baf51e7739a4d176284d2e38e1755afeafcd2ee0 migration: ensure qemu_fflush() always writes full data amount a8ec4437cd52b2258c77d6b4195c927139c4ced5 migration: remove use of qemu_bufopen from vmstate tests
NB, this depends on many changes that were merged during 2.5/2.6, to support generic I/O channels
- QEMU 2.7