aboutsummaryrefslogtreecommitdiff
path: root/migration/tls.c
AgeCommit message (Collapse)AuthorFilesLines
2019-03-25migration: add support for a "tls-authz" migration parameterDaniel P. Berrange1-1/+1
The QEMU instance that runs as the server for the migration data transport (ie the target QEMU) needs to be able to configure access control so it can prevent unauthorized clients initiating an incoming migration. This adds a new 'tls-authz' migration parameter that is used to provide the QOM ID of a QAuthZ subclass instance that provides the access control check. This is checked against the x509 certificate obtained during the TLS handshake. For example, when starting a QEMU for incoming migration, it is possible to give an example identity of the source QEMU that is intended to be connecting later: $QEMU \ -monitor stdio \ -incoming defer \ ...other args... (qemu) object_add tls-creds-x509,id=tls0,dir=/home/berrange/qemutls,\ endpoint=server,verify-peer=yes \ (qemu) object_add authz-simple,id=auth0,identity=CN=laptop.example.com,,\ O=Example Org,,L=London,,ST=London,,C=GB \ (qemu) migrate_incoming tcp:localhost:9000 Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2018-03-06qio: non-default context for TLS handshakePeter Xu1-0/+2
A new parameter "context" is added to qio_channel_tls_handshake() is to allow the TLS to be run on a non-default context. Still, no functional change. Signed-off-by: Peter Xu <peterx@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2018-02-06migration: Route errors down through migration_channel_connectDr. David Alan Gilbert1-2/+1
Route async errors (especially from sockets) down through migration_channel_connect and on to migrate_fd_connect where they can be cleaned up. Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-10-23migration: Improve migration thread error handlingJuan Quintela1-1/+0
We now report errors also when we finish migration, not only on info migrate. We plan to use this error from several places, and we want the first error to happen to win, so we add an mutex to order it. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-06-13migration: Move migration.h to migration/Juan Quintela1-1/+1
Nothing uses it outside of migration.h Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2017-06-13migration: Remove MigrationState from migration_channel_incomming()Juan Quintela1-1/+1
All callers were calling migrate_get_current(), so do it inside the function. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Peter Xu <peterx@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com>
2017-06-01migration: Export tls.c functions in its own fileJuan Quintela1-0/+1
Just for the functions exported from tls.c. Notice that we can't remove the migration/migration.h include from tls.c because it access directly MigrationState for the tls params. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
2017-05-18migration: Split migration/channel.c for channel operationsJuan Quintela1-0/+1
Create an include for its exported functions. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> --- Add proper header
2017-05-04migration: to_dst_file at that point is NULLJuan Quintela1-1/+0
We have just arrived as: migration.c: qemu_migrate() .... s = migrate_init() <- puts it to NULL .... {tcp,unix}_start_outgoing_migration -> socket_outgoing_migration migration_channel_connect() sets to_dst_file if tls is enabled, we do another round through migrate_channel_tls_connect(), but we only set it up if there is no error. So we don't need the assignation. I am removing it to remove in the follwing patches the knowledge about MigrationState in that two files. Signed-off-by: Juan Quintela <quintela@redhat.com> Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com>
2017-03-16migration: use "" as the default for tls-creds/hostnameDaniel P. Berrange1-1/+1
The tls-creds parameter has a default value of NULL indicating that TLS should not be used. Setting it to non-NULL enables use of TLS. Once tls-creds are set to a non-NULL value via the monitor, it isn't possible to set them back to NULL again, due to current implementation limitations. The empty string is not a valid QObject identifier, so this switches to use "" as the default, indicating that TLS will not be used The tls-hostname parameter has a default value of NULL indicating the the hostname from the migrate connection URI should be used. Again, once tls-hostname is set non-NULL, to override the default hostname for x509 cert validation, it isn't possible to reset it back to NULL via the monitor. The empty string is not a valid hostname, so this switches to use "" as the default, indicating that the migrate URI hostname should be used. Using "" as the default for both, also means that the monitor commands "info migrate_parameters" / "query-migrate-parameters" will report existance of tls-creds/tls-parameters even when set to their default values. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Juan Quintela <quintela@redhat.com>
2017-01-23io: change the QIOTask callback signatureDaniel P. Berrange1-9/+10
Currently the QIOTaskFunc signature takes an Object * for the source, and an Error * for any error. We also need to be able to provide a result pointer. Rather than continue to add parameters to QIOTaskFunc, remove the existing ones and simply pass the QIOTask object instead. This has methods to access all the other data items required in the callback impl. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-10-27migration: set name for all I/O channels createdDaniel P. Berrange1-0/+2
Ensure that all I/O channels created for migration are given names to distinguish their respective roles. Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2016-06-16migration: rename functions to starting migrationsDaniel P. Berrange1-9/+9
Apply the following renames for starting incoming migration: process_incoming_migration -> migration_fd_process_incoming migration_set_incoming_channel -> migration_channel_process_incoming migration_tls_set_incoming_channel -> migration_tls_channel_process_incoming and for starting outgoing migration: migration_set_outgoing_channel -> migration_channel_connect migration_tls_set_outgoing_channel -> migration_tls_channel_connect Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 1464776234-9910-3-git-send-email-berrange@redhat.com Message-Id: <1464776234-9910-3-git-send-email-berrange@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-05-26migration: add support for encrypting data with TLSDaniel P. Berrange1-0/+161
This extends the migration_set_incoming_channel and migration_set_outgoing_channel methods so that they will automatically wrap the QIOChannel in a QIOChannelTLS instance if TLS credentials are configured in the migration parameters. This allows TLS to work for tcp, unix, fd and exec migration protocols. It does not (currently) work for RDMA since it does not use these APIs, but it is unlikely that TLS would be desired with RDMA anyway since it would degrade the performance to that seen with TCP defeating the purpose of using RDMA. 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 Thanks to earlier improvements to error reporting, TLS errors can be seen 'info migrate' when doing a detached migration. For example: (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: TLS handshake failed: The TLS connection was non-properly terminated. Or (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 Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1461751518-12128-27-git-send-email-berrange@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>