bwlp/qemu.git/crypto/Makefile.objs, branch spice_video_codecs

meson: convert crypto directory to Meson

2020-08-21T10:30:16+00:00

Signed-off-by: Marc-André Lureau Signed-off-by: Paolo Bonzini

libqemuutil, qapi, trace: convert to meson

2020-08-21T10:30:08+00:00

This shows how to do some "computations" in meson.build using its array and dictionary data structures, and also a basic usage of the sourceset module for conditional compilation. Notice the new "if have_system" part of util/meson.build, which fixes a bug in the old build system was buggy: util/dbus.c was built even for non-softmmu builds, but the dependency on -lgio was lost when the linking was done through libqemuutil.a. Because all of its users required gio otherwise, the bug was hidden. Meson instead propagates libqemuutil's dependencies down to its users, and shows the problem. Signed-off-by: Paolo Bonzini

crypto: Add tls-cipher-suites object

2020-07-03T16:16:01+00:00

On the host OS, various aspects of TLS operation are configurable. In particular it is possible for the sysadmin to control the TLS cipher/protocol algorithms that applications are permitted to use. * Any given crypto library has a built-in default priority list defined by the distro maintainer of the library package (or by upstream). * The "crypto-policies" RPM (or equivalent host OS package) provides a config file such as "/etc/crypto-policies/config", where the sysadmin can set a high level (library-independent) policy. The "update-crypto-policies --set" command (or equivalent) is used to translate the global policy to individual library representations, producing files such as "/etc/crypto-policies/back-ends/*.config". The generated files, if present, are loaded by the various crypto libraries to override their own built-in defaults. For example, the GNUTLS library may read "/etc/crypto-policies/back-ends/gnutls.config". * A management application (or the QEMU user) may overide the system-wide crypto-policies config via their own config, if they need to diverge from the former. Thus the priority order is "QEMU user config" > "crypto-policies system config" > "library built-in config". Introduce the "tls-cipher-suites" object for exposing the ordered list of permitted TLS cipher suites from the host side to the guest firmware, via fw_cfg. The list is represented as an array of bytes. The priority at which the host-side policy is retrieved is given by the "priority" property of the new object type. For example, "priority=@SYSTEM" may be used to refer to "/etc/crypto-policies/back-ends/gnutls.config" (given that QEMU uses GNUTLS). The firmware uses the IANA_TLS_CIPHER array for configuring guest-side TLS, for example in UEFI HTTPS Boot. [Description from Daniel P. Berrangé, edited by Laszlo Ersek.] Signed-off-by: Philippe Mathieu-Daudé Reviewed-by: Daniel P. Berrangé Acked-by: Laszlo Ersek Message-Id: <20200623172726.21040-2-philmd@redhat.com>

crypto/linux_keyring: add 'secret_keyring' secret object.

2020-06-15T10:33:51+00:00

Add the ability for the secret object to obtain secret data from the Linux in-kernel key managment and retention facility, as an extra option to the existing ones: reading from a file or passing directly as a string. The secret is identified by the key serial number. The upper layers need to instantiate the key and make sure the QEMU process has access permissions to read it. Signed-off-by: Alexey Krasikov - Fixed up detection logic default behaviour in configure Signed-off-by: Daniel P. Berrangé

crypto/secret: move main logic from 'secret' to 'secret_common'.

2020-06-15T10:33:51+00:00

Create base class 'common secret'. Move common data and logic from 'secret' to 'common_secret' class. This allowed adding abstraction layer for easier adding new 'secret' objects in future. Convert 'secret' class to child from basic 'secret_common' with 'data' and 'file' properties. Signed-off-by: Alexey Krasikov Signed-off-by: Daniel P. Berrangé

crypto: add "none" random provider

2020-06-15T10:33:50+00:00

In case of not using random-number needing feature, it makes sense to skip RNG init too. This is especially helpful when QEMU is sandboxed in Stubdomain under Xen, where there is very little entropy so initial getrandom() call delays the startup several seconds. In that setup, no random bytes are needed at all. Signed-off-by: Marek Marczykowski-Górecki Signed-off-by: Daniel P. Berrangé

stubs: replace stubs with lnot if applicable

2019-12-17T18:32:48+00:00

The stubs mechanism relies on static libraries and compilation order, which is a bit brittle and should be avoided unless necessary. Replace it with Boolean operations on CONFIG_* symbols. Signed-off-by: Paolo Bonzini

crypto: move common bits for all emulators to libqemuutil

2019-12-17T18:32:48+00:00

qcrypto_random_*, AES and qcrypto_init do not need to be linked as a whole and are the only parts that are used by user-mode emulation. Place them in libqemuutil, so that whatever needs them will pick them up automatically. Signed-off-by: Paolo Bonzini

crypto: add support for gcrypt's native XTS impl

2019-10-28T15:20:28+00:00

Libgcrypt 1.8.0 added support for the XTS mode. Use this because long term we wish to delete QEMU's XTS impl to avoid carrying private crypto algorithm impls. As an added benefit, using this improves performance from 531 MB/sec to 670 MB/sec, since we are avoiding several layers of function call indirection. This is even more noticable with the gcrypt builds in Fedora or RHEL-8 which have a non-upstream patch for FIPS mode which does mutex locking. This is catastrophic for encryption performance with small block sizes, meaning this patch improves encryption from 240 MB/sec to 670 MB/sec. Reviewed-by: Philippe Mathieu-Daudé Reviewed-by: Stefano Garzarella Signed-off-by: Daniel P. Berrangé

build: Link user-only with crypto random number objects

2019-05-22T16:38:54+00:00

For user-only, we require only the random number bits of the crypto subsystem. Rename crypto-aes-obj-y to crypto-user-obj-y, and add the random number objects, plus init.o to handle any extra stuff the crypto library requires. Move the crypto libraries from libs_softmmu and libs_tools to LIBS, so that they are universally used. Reviewed-by: Daniel P. Berrangé Signed-off-by: Richard Henderson