riscv/qemu - qemu - Gitea: Git with a cup of tea

Commit Graph

Author	SHA1	Message	Date
Daniel P. Berrangé	305233349b	crypto: drop gnutls debug logging support GNUTLS already supports dynamically enabling its logging at runtime by setting the env var 'GNUTLS_DEBUG_LEVEL=10', so there is no need to re-invent this logic in QEMU in a way that requires a re-compile. Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	2 years ago
Daniel P. Berrangé	ea7a6802c7	crypto: drop gcrypt thread initialization code This is only required on gcrypt < 1.6.0, and is thus obsolete since commit `b33a84632a` Author: Daniel P. Berrangé <berrange@redhat.com> Date: Fri May 14 13:04:08 2021 +0100 crypto: bump min gcrypt to 1.8.0, dropping RHEL-7 support Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	5 years ago
Richard W.M. Jones	d6cca8e111	crypto: Remove use of GCRYPT_VERSION macro. According to the gcrypt documentation it's intended that gcry_check_version() is called with the minimum version of gcrypt needed by the program, not the version from the <gcrypt.h> header file that happened to be installed when qemu was compiled. Indeed the gcrypt.h header says that you shouldn't use the GCRYPT_VERSION macro. This causes the following failure: qemu-img: Unable to initialize gcrypt if a slightly older version of libgcrypt is installed with a newer qemu, even though the slightly older version works fine. This can happen with RPM packaging which uses symbol versioning to determine automatically which libgcrypt is required by qemu, which caused the following bug in RHEL 8: https://bugzilla.redhat.com/show_bug.cgi?id=1840485 qemu actually requires libgcrypt >= 1.5.0, so we might put the string "1.5.0" here. However since 1.5.0 was released in 2011, it hardly seems we need to check that. So I replaced GCRYPT_VERSION with NULL. Perhaps in future if we move to requiring a newer version of gcrypt we could put a literal string here. Signed-off-by: Richard W.M. Jones <rjones@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	6 years ago
Thomas Huth	b7cbb8741b	crypto: Fix LGPL information in the file headers It's either "GNU Library General Public License version 2" or "GNU Lesser General Public License version 2.1", but there was no "version 2.0" of the "Lesser" license. So assume that version 2.1 is meant here. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	8 years ago
Daniel P. Berrangé	dea7a64e4c	crypto: require libgcrypt >= 1.5.0 for building QEMU libgcrypt 1.5.0 was released in 2011 and all the distros that are build target platforms for QEMU [1] include it: RHEL-7: 1.5.3 Debian (Stretch): 1.7.6 Debian (Jessie): 1.6.3 OpenBSD (ports): 1.8.2 FreeBSD (ports): 1.8.3 OpenSUSE Leap 15: 1.8.2 Ubuntu (Xenial): 1.6.5 macOS (Homebrew): 1.8.3 Based on this, it is reasonable to require libgcrypt >= 1.5.0 in QEMU which allows for some conditional version checks in the code to be removed. [1] https://qemu.weilnetz.de/doc/qemu-doc.html#Supported-build-platforms Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	8 years ago
Daniel P. Berrangé	a0722409bc	crypto: require gnutls >= 3.1.18 for building QEMU gnutls 3.0.0 was released in 2011 and all the distros that are build target platforms for QEMU [1] include it: RHEL-7: 3.1.18 Debian (Stretch): 3.5.8 Debian (Jessie): 3.3.8 OpenBSD (ports): 3.5.18 FreeBSD (ports): 3.5.18 OpenSUSE Leap 15: 3.6.2 Ubuntu (Xenial): 3.4.10 macOS (Homebrew): 3.5.19 Based on this, it is reasonable to require gnutls >= 3.1.18 in QEMU which allows for all conditional version checks in the code to be removed. [1] https://qemu.weilnetz.de/doc/qemu-doc.html#Supported-build-platforms Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>	8 years ago
Geert Martin Ijewski	a37278169d	crypto: qcrypto_random_bytes() now works on windows w/o any other crypto libs If no crypto library is included in the build, QEMU uses qcrypto_random_bytes() to generate random data. That function tried to open /dev/urandom or /dev/random and if opening both files failed it errored out. Those files obviously do not exist on windows, so there the code uses CryptGenRandom(). Furthermore there was some refactoring and a new function qcrypto_random_init() was introduced. If a proper crypto library (gnutls or libgcrypt) is included in the build, this function does nothing. If neither is included it initializes the (platform specific) handles that are used by qcrypto_random_bytes(). Either: * a handle to /dev/urandom \| /dev/random on unix like systems * a handle to a cryptographic service provider on windows Signed-off-by: Geert Martin Ijewski <gm.ijewski@web.de> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>	9 years ago
Daniel P. Berrange	373166636b	crypto: fix initialization of gcrypt threading The gcrypt threads implementation must be set before calling any other gcrypt APIs, especially gcry_check_version(), since that triggers initialization of the random pool. After that is initialized, changes to the threads impl won't be honoured by the random pool code. This means that gcrypt will think thread locking is needed and so try to acquire the random pool mutex, but this is NULL as no threads impl was set originally. This results in a crash in the random pool code. For the same reasons, we must set the gcrypt threads impl before calling gnutls_init, since that will also trigger gcry_check_version Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>	10 years ago
Gonglei	d9269b274a	crypto: fix building complaint gnutls commit 846753877d renamed LIBGNUTLS_VERSION_NUMBER to GNUTLS_VERSION_NUMBER. If using gnutls before that verion, we'll get the below warning: crypto/tlscredsx509.c:618:5: warning: "GNUTLS_VERSION_NUMBER" is not defined Because gnutls 3.x still defines LIBGNUTLS_VERSION_NUMBER for back compat, Let's use LIBGNUTLS_VERSION_NUMBER instead of GNUTLS_VERSION_NUMBER to fix building complaint. Signed-off-by: Gonglei <arei.gonglei@huawei.com> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>	10 years ago
Markus Armbruster	da34e65cb4	include/qemu/osdep.h: Don't include qapi/error.h Commit `57cb38b` included qapi/error.h into qemu/osdep.h to get the Error typedef. Since then, we've moved to include qemu/osdep.h everywhere. Its file comment explains: "To avoid getting into possible circular include dependencies, this file should not include any other QEMU headers, with the exceptions of config-host.h, compiler.h, os-posix.h and os-win32.h, all of which are doing a similar job to this file and are under similar constraints." qapi/error.h doesn't do a similar job, and it doesn't adhere to similar constraints: it includes qapi-types.h. That's in excess of 100KiB of crap most .c files don't actually need. Add the typedef to qemu/typedefs.h, and include that instead of qapi/error.h. Include qapi/error.h in .c files that need it and don't get it now. Include qapi-types.h in qom/object.h for uint16List. Update scripts/clean-includes accordingly. Update it further to match reality: replace config.h by config-target.h, add sysemu/os-posix.h, sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h comment quoted above similarly. This reduces the number of objects depending on qapi/error.h from "all of them" to less than a third. Unfortunately, the number depending on qapi-types.h shrinks only a little. More work is needed for that one. Signed-off-by: Markus Armbruster <armbru@redhat.com> [Fix compilation without the spice devel packages. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	11 years ago
Peter Maydell	42f7a448db	crypto: Clean up includes Clean up includes so that osdep.h is included first and headers which it implies are not included manually. This commit was created with scripts/clean-includes. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 1453832250-766-3-git-send-email-peter.maydell@linaro.org	11 years ago
Daniel P. Berrange	91bfcdb01d	crypto: allow use of nettle/gcrypt to be selected explicitly Currently the choice of whether to use nettle or gcrypt is made based on what gnutls is linked to. There are times when it is desirable to be able to force build against a specific library. For example, if testing changes to QEMU's crypto code all 3 possible backends need to be checked regardless of what the local gnutls uses. It is also desirable to be able to enable nettle/gcrypt for cipher/hash algorithms, without enabling gnutls for TLS support. This gives two new configure flags, which allow the following possibilities Automatically determine nettle vs gcrypt from what gnutls links to (recommended to minimize number of crypto libraries linked to) ./configure Automatically determine nettle vs gcrypt based on which is installed ./configure --disable-gnutls Force use of nettle ./configure --enable-nettle Force use of gcrypt ./configure --enable-gcrypt Force use of built-in AES & crippled-DES ./configure --disable-nettle --disable-gcrypt Signed-off-by: Daniel P. Berrange <berrange@redhat.com>	11 years ago
Daniel P. Berrange	62893b67cd	crypto: add a gcrypt cipher implementation If we are linking to gnutls already and gnutls is built against gcrypt, then we should use gcrypt as a cipher backend in preference to our built-in backend. This will be used when linking against GNUTLS 1.x and many GNUTLS 2.x versions. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-6-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	11 years ago
Daniel P. Berrange	ddbb0d0966	crypto: introduce new module for computing hash digests Introduce a new crypto/ directory that will (eventually) contain all the cryptographic related code. This initially defines a wrapper for initializing gnutls and for computing hashes with gnutls. The former ensures that gnutls is guaranteed to be initialized exactly once in QEMU regardless of CLI args. The block quorum code currently fails to initialize gnutls so it only works by luck, if VNC server TLS is not requested. The hash APIs avoids the need to litter the rest of the code with preprocessor checks and simplifies callers by allocating the correct amount of memory for the requested hash. Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Message-Id: <1435770638-25715-2-git-send-email-berrange@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>	11 years ago

14 Commits (master)