summaryrefslogtreecommitdiffstats
path: root/migration/tls.c
Commit message (Collapse)AuthorAgeFilesLines
* migration: Fix Lesser GPL version numberChetan Pant2020-11-151-1/+1
| | | | | | | | | | | | There is no "version 2" of the "Lesser" General Public License. It is either "GPL version 2.0" or "Lesser GPL version 2.1". This patch replaces all occurrences of "Lesser GPL version 2" with "Lesser GPL version 2.1" in comment section. Signed-off-by: Chetan Pant <chetan4windows@gmail.com> Message-Id: <20201023123130.19656-1-chetan4windows@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Thomas Huth <thuth@redhat.com>
* migration/tls: extract migration_tls_client_create for common-useChuan Zheng2020-09-251-8/+18
| | | | | | | | | | | migration_tls_client_create will be used in multifd-tls, let's extract it. Signed-off-by: Chuan Zheng <zhengchuan@huawei.com> Signed-off-by: Yan Jin <jinyan12@huawei.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <1600139042-104593-3-git-send-email-zhengchuan@huawei.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
* migration/tls: save hostname into MigrationStateChuan Zheng2020-09-251-0/+2
| | | | | | | | | | hostname is need in multifd-tls, save hostname into MigrationState. Signed-off-by: Chuan Zheng <zhengchuan@huawei.com> Signed-off-by: Yan Jin <jinyan12@huawei.com> Message-Id: <1600139042-104593-2-git-send-email-zhengchuan@huawei.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
* migration: tls: fix memory leak in migration_tls_get_credsZhenyu Ye2020-08-281-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently migration_tls_get_creds() adds the reference of creds but there was no place to unref it. So the OBJECT(creds) will never be freed and result in memory leak. The leak stack: Direct leak of 104 byte(s) in 1 object(s) allocated from: #0 0xffffa88bd20b in __interceptor_malloc (/usr/lib64/libasan.so.4+0xd320b) #1 0xffffa7f0cb1b in g_malloc (/usr/lib64/libglib-2.0.so.0+0x58b1b) #2 0x14b58cb in object_new_with_type qom/object.c:634 #3 0x14b597b in object_new qom/object.c:645 #4 0x14c0e4f in user_creatable_add_type qom/object_interfaces.c:59 #5 0x141c78b in qmp_object_add qom/qom-qmp-cmds.c:312 #6 0x140e513 in qmp_marshal_object_add qapi/qapi-commands-qom.c:279 #7 0x176ba97 in do_qmp_dispatch qapi/qmp-dispatch.c:165 #8 0x176bee7 in qmp_dispatch qapi/qmp-dispatch.c:208 #9 0x136e337 in monitor_qmp_dispatch monitor/qmp.c:150 #10 0x136eae3 in monitor_qmp_bh_dispatcher monitor/qmp.c:239 #11 0x1852e93 in aio_bh_call util/async.c:89 #12 0x18531b7 in aio_bh_poll util/async.c:117 #13 0x18616bf in aio_dispatch util/aio-posix.c:459 #14 0x1853f37 in aio_ctx_dispatch util/async.c:268 #15 0xffffa7f06a7b in g_main_context_dispatch (/usr/lib64/libglib-2.0.so.0+0x52a7b) Since we're fine to use the borrowed reference when using the creds, so just remove the object_ref() in migration_tls_get_creds(). Signed-off-by: Zhenyu Ye <yezhenyu2@huawei.com> Message-Id: <20200722033228.71-1-yezhenyu2@huawei.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
* migration: add support for a "tls-authz" migration parameterDaniel P. Berrange2019-03-251-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>
* qio: non-default context for TLS handshakePeter Xu2018-03-061-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>
* migration: Route errors down through migration_channel_connectDr. David Alan Gilbert2018-02-061-2/+1Star
| | | | | | | | | | | 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>
* migration: Improve migration thread error handlingJuan Quintela2017-10-231-1/+0Star
| | | | | | | | | 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>
* migration: Move migration.h to migration/Juan Quintela2017-06-131-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>
* migration: Remove MigrationState from migration_channel_incomming()Juan Quintela2017-06-131-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>
* migration: Export tls.c functions in its own fileJuan Quintela2017-06-011-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>
* migration: Split migration/channel.c for channel operationsJuan Quintela2017-05-181-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
* migration: to_dst_file at that point is NULLJuan Quintela2017-05-041-1/+0Star
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* migration: use "" as the default for tls-creds/hostnameDaniel P. Berrange2017-03-161-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>
* io: change the QIOTask callback signatureDaniel P. Berrange2017-01-231-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>
* migration: set name for all I/O channels createdDaniel P. Berrange2016-10-271-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>
* migration: rename functions to starting migrationsDaniel P. Berrange2016-06-161-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>
* migration: add support for encrypting data with TLSDaniel P. Berrange2016-05-261-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>