qemu/crypto/Makefile.objs

crypto-obj-y = init.o
crypto-obj-y += hash.o
crypto-obj-y += aes.o
crypto-obj-y += desrfb.o
crypto-obj-y += cipher.o
crypto-obj-y += tlscreds.o
crypto-obj-y += tlscredsanon.o
crypto-obj-y += tlscredsx509.o
crypto-obj-y += tlssession.o
crypto-obj-y += secret.o

# Let the userspace emulators avoid linking gnutls/etc
crypto-aes-obj-y = aes.o
crypto: move crypto objects out of libqemuutil.la Future patches will be adding more crypto related APIs which rely on QOM infrastructure. This creates a problem, because QOM relies on library constructors to register objects. When you have a file in a static .a library though which is only referenced by a constructor the linker is dumb and will drop that file when linking to the final executable :-( The only workaround for this is to link the .a library to the executable using the -Wl,--whole-archive flag, but this creates its own set of problems because QEMU is relying on lazy linking for libqemuutil.a. Using --whole-archive majorly increases the size of final executables as they now contain a bunch of object code they don't actually use. The least bad option is to thus not include the crypto objects in libqemuutil.la, and instead define a crypto-obj-y variable that is referenced directly by all the executables that need this code (tools + softmmu, but not qemu-ga). We avoid pulling entire of crypto-obj-y into the userspace emulators as that would force them to link to gnutls too, which is not required. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 2015-09-02 12:57:27 +03:00			`crypto-obj-y = init.o`
			`crypto-obj-y += hash.o`
			`crypto-obj-y += aes.o`
			`crypto-obj-y += desrfb.o`
			`crypto-obj-y += cipher.o`
crypto: introduce new base module for TLS credentials Introduce a QCryptoTLSCreds class to act as the base class for storing TLS credentials. This will be later subclassed to provide handling of anonymous and x509 credential types. The subclasses will be user creatable objects, so instances can be created & deleted via 'object-add' and 'object-del' QMP commands respectively, or via the -object command line arg. If the credentials cannot be initialized an error will be reported as a QMP reply, or on stderr respectively. The idea is to make it possible to represent and manage TLS credentials independently of the network service that is using them. This will enable multiple services to use the same set of credentials and minimize code duplication. A later patch will convert the current VNC server TLS code over to use this object. The representation of credentials will be functionally equivalent to that currently implemented in the VNC server with one exception. The new code has the ability to (optionally) load a pre-generated set of diffie-hellman parameters, if the file dh-params.pem exists, whereas the current VNC server will always generate them on startup. This is beneficial for admins who wish to avoid the (small) time sink of generating DH parameters at startup and/or avoid depleting entropy. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 2015-03-13 20:39:26 +03:00			`crypto-obj-y += tlscreds.o`
crypto: introduce new module for TLS anonymous credentials Introduce a QCryptoTLSCredsAnon class which is used to manage anonymous TLS credentials. Use of this class is generally discouraged since it does not offer strong security, but it is required for backwards compatibility with the current VNC server implementation. Simple example CLI configuration: $QEMU -object tls-creds-anon,id=tls0,endpoint=server Example using pre-created diffie-hellman parameters $QEMU -object tls-creds-anon,id=tls0,endpoint=server,\ dir=/path/to/creds/dir The 'id' value in the -object args will be used to associate the credentials with the network services. For example, when the VNC server is later converted it would use $QEMU -object tls-creds-anon,id=tls0,.... \ -vnc 127.0.0.1:1,tls-creds=tls0 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> 2015-03-13 20:39:26 +03:00			`crypto-obj-y += tlscredsanon.o`
crypto: introduce new module for TLS x509 credentials Introduce a QCryptoTLSCredsX509 class which is used to manage x509 certificate TLS credentials. This will be the preferred credential type offering strong security characteristics Example CLI configuration: $QEMU -object tls-creds-x509,id=tls0,endpoint=server,\ dir=/path/to/creds/dir,verify-peer=yes The 'id' value in the -object args will be used to associate the credentials with the network services. For example, when the VNC server is later converted it would use $QEMU -object tls-creds-x509,id=tls0,.... \ -vnc 127.0.0.1:1,tls-creds=tls0 Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> 2015-03-13 20:39:26 +03:00			`crypto-obj-y += tlscredsx509.o`
crypto: introduce new module for handling TLS sessions Introduce a QCryptoTLSSession object that will encapsulate all the code for setting up and using a client/sever TLS session. This isolates the code which depends on the gnutls library, avoiding #ifdefs in the rest of the codebase, as well as facilitating any possible future port to other TLS libraries, if desired. It makes use of the previously defined QCryptoTLSCreds object to access credentials to use with the session. It also includes further unit tests to validate the correctness of the TLS session handshake and certificate validation. This is functionally equivalent to the current TLS session handling code embedded in the VNC server, and will obsolete it. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 2015-03-02 20:23:31 +03:00			`crypto-obj-y += tlssession.o`
crypto: add QCryptoSecret object class for password/key handling Introduce a new QCryptoSecret object class which will be used for providing passwords and keys to other objects which need sensitive credentials. The new object can provide secret values directly as properties, or indirectly via a file. The latter includes support for file descriptor passing syntax on UNIX platforms. Ordinarily passing secret values directly as properties is insecure, since they are visible in process listings, or in log files showing the CLI args / QMP commands. It is possible to use AES-256-CBC to encrypt the secret values though, in which case all that is visible is the ciphertext. For ad hoc developer testing though, it is fine to provide the secrets directly without encryption so this is not explicitly forbidden. The anticipated scenario is that libvirtd will create a random master key per QEMU instance (eg /var/run/libvirt/qemu/$VMNAME.key) and will use that key to encrypt all passwords it provides to QEMU via '-object secret,....'. This avoids the need for libvirt (or other mgmt apps) to worry about file descriptor passing. It also makes life easier for people who are scripting the management of QEMU, for whom FD passing is significantly more complex. Providing data inline (insecure, only for ad hoc dev testing) $QEMU -object secret,id=sec0,data=letmein Providing data indirectly in raw format printf "letmein" > mypasswd.txt $QEMU -object secret,id=sec0,file=mypasswd.txt Providing data indirectly in base64 format $QEMU -object secret,id=sec0,file=mykey.b64,format=base64 Providing data with encryption $QEMU -object secret,id=master0,file=mykey.b64,format=base64 \ -object secret,id=sec0,data=[base64 ciphertext],\ keyid=master0,iv=[base64 IV],format=base64 Note that 'format' here refers to the format of the ciphertext data. The decrypted data must always be in raw byte format. More examples are shown in the updated docs. Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 2015-10-14 11:58:38 +03:00			`crypto-obj-y += secret.o`
crypto: move crypto objects out of libqemuutil.la Future patches will be adding more crypto related APIs which rely on QOM infrastructure. This creates a problem, because QOM relies on library constructors to register objects. When you have a file in a static .a library though which is only referenced by a constructor the linker is dumb and will drop that file when linking to the final executable :-( The only workaround for this is to link the .a library to the executable using the -Wl,--whole-archive flag, but this creates its own set of problems because QEMU is relying on lazy linking for libqemuutil.a. Using --whole-archive majorly increases the size of final executables as they now contain a bunch of object code they don't actually use. The least bad option is to thus not include the crypto objects in libqemuutil.la, and instead define a crypto-obj-y variable that is referenced directly by all the executables that need this code (tools + softmmu, but not qemu-ga). We avoid pulling entire of crypto-obj-y into the userspace emulators as that would force them to link to gnutls too, which is not required. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> 2015-09-02 12:57:27 +03:00
			`# Let the userspace emulators avoid linking gnutls/etc`
			`crypto-aes-obj-y = aes.o`