aboutsummaryrefslogtreecommitdiff
path: root/crypto
AgeCommit message (Collapse)Author
2020-08-21meson: convert crypto directory to MesonMarc-André Lureau
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-08-21libqemuutil, qapi, trace: convert to mesonPaolo Bonzini
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 <pbonzini@redhat.com>
2020-08-21trace: switch position of headers to what Meson requiresPaolo Bonzini
Meson doesn't enjoy the same flexibility we have with Make in choosing the include path. In particular the tracing headers are using $(build_root)/$(<D). In order to keep the include directives unchanged, the simplest solution is to generate headers with patterns like "trace/trace-audio.h" and place forwarding headers in the source tree such that for example "audio/trace.h" includes "trace/trace-audio.h". This patch is too ugly to be applied to the Makefiles now. It's only a way to separate the changes to the tracing header files from the Meson rewrite of the tracing logic. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-07-10qom: Put name parameter before value / visitor parameterMarkus Armbruster
The object_property_set_FOO() setters take property name and value in an unusual order: void object_property_set_FOO(Object *obj, FOO_TYPE value, const char *name, Error **errp) Having to pass value before name feels grating. Swap them. Same for object_property_set(), object_property_get(), and object_property_parse(). Convert callers with this Coccinelle script: @@ identifier fun = { object_property_get, object_property_parse, object_property_set_str, object_property_set_link, object_property_set_bool, object_property_set_int, object_property_set_uint, object_property_set, object_property_set_qobject }; expression obj, v, name, errp; @@ - fun(obj, v, name, errp) + fun(obj, name, v, errp) Chokes on hw/arm/musicpal.c's lcd_refresh() with the unhelpful error message "no position information". Convert that one manually. Fails to convert hw/arm/armsse.c, because Coccinelle gets confused by ARMSSE being used both as typedef and function-like macro there. Convert manually. Fails to convert hw/rx/rx-gdbsim.c, because Coccinelle gets confused by RXCPU being used both as typedef and function-like macro there. Convert manually. The other files using RXCPU that way don't need conversion. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com> Message-Id: <20200707160613.848843-27-armbru@redhat.com> [Straightforwad conflict with commit 2336172d9b "audio: set default value for pcspk.iobase property" resolved]
2020-07-09Merge remote-tracking branch 'remotes/philmd-gitlab/tags/fw_cfg-20200704' ↵Peter Maydell
into staging firmware (and crypto) patches - add the tls-cipher-suites object, - add the ability to QOM objects to produce data consumable by the fw_cfg device, - let the tls-cipher-suites object implement the FW_CFG_DATA_GENERATOR interface. This is required by EDK2 'HTTPS Boot' feature of OVMF to tell the guest which TLS ciphers it can use. CI jobs results: https://travis-ci.org/github/philmd/qemu/builds/704724619 https://gitlab.com/philmd/qemu/-/pipelines/162938106 https://cirrus-ci.com/build/4682977303068672 # gpg: Signature made Sat 04 Jul 2020 17:37:08 BST # gpg: using RSA key FAABE75E12917221DCFD6BB2E3E32C2CDEADC0DE # gpg: Good signature from "Philippe Mathieu-Daudé (F4BUG) <f4bug@amsat.org>" [full] # Primary key fingerprint: FAAB E75E 1291 7221 DCFD 6BB2 E3E3 2C2C DEAD C0DE * remotes/philmd-gitlab/tags/fw_cfg-20200704: crypto/tls-cipher-suites: Produce fw_cfg consumable blob softmmu/vl: Allow -fw_cfg 'gen_id' option to use the 'etc/' namespace softmmu/vl: Let -fw_cfg option take a 'gen_id' argument hw/nvram/fw_cfg: Add the FW_CFG_DATA_GENERATOR interface crypto: Add tls-cipher-suites object Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2020-07-06qcrypto/luks: implement encryption key managementMaxim Levitsky
Next few patches will expose that functionality to the user. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200608094030.670121-3-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-06qcrypto/core: add generic infrastructure for crypto options amendmentMaxim Levitsky
This will be used first to implement luks keyslot management. block_crypto_amend_opts_init will be used to convert qemu-img cmdline to QCryptoBlockAmendOptions Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Message-Id: <20200608094030.670121-2-mlevitsk@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-07-03crypto/tls-cipher-suites: Produce fw_cfg consumable blobPhilippe Mathieu-Daudé
Since our format is consumable by the fw_cfg device, we can implement the FW_CFG_DATA_GENERATOR interface. Example of use to dump the cipher suites (if tracing enabled): $ qemu-system-x86_64 -S \ -object tls-cipher-suites,id=mysuite1,priority=@SYSTEM \ -fw_cfg name=etc/path/to/ciphers,gen_id=mysuite1 \ -trace qcrypto\* 1590664444.197123:qcrypto_tls_cipher_suite_priority priority: @SYSTEM 1590664444.197219:qcrypto_tls_cipher_suite_info data=[0x13,0x02] version=TLS1.3 name=TLS_AES_256_GCM_SHA384 1590664444.197228:qcrypto_tls_cipher_suite_info data=[0x13,0x03] version=TLS1.3 name=TLS_CHACHA20_POLY1305_SHA256 1590664444.197233:qcrypto_tls_cipher_suite_info data=[0x13,0x01] version=TLS1.3 name=TLS_AES_128_GCM_SHA256 1590664444.197236:qcrypto_tls_cipher_suite_info data=[0x13,0x04] version=TLS1.3 name=TLS_AES_128_CCM_SHA256 1590664444.197240:qcrypto_tls_cipher_suite_info data=[0xc0,0x30] version=TLS1.2 name=TLS_ECDHE_RSA_AES_256_GCM_SHA384 1590664444.197245:qcrypto_tls_cipher_suite_info data=[0xcc,0xa8] version=TLS1.2 name=TLS_ECDHE_RSA_CHACHA20_POLY1305 1590664444.197250:qcrypto_tls_cipher_suite_info data=[0xc0,0x14] version=TLS1.0 name=TLS_ECDHE_RSA_AES_256_CBC_SHA1 1590664444.197254:qcrypto_tls_cipher_suite_info data=[0xc0,0x2f] version=TLS1.2 name=TLS_ECDHE_RSA_AES_128_GCM_SHA256 1590664444.197258:qcrypto_tls_cipher_suite_info data=[0xc0,0x13] version=TLS1.0 name=TLS_ECDHE_RSA_AES_128_CBC_SHA1 1590664444.197261:qcrypto_tls_cipher_suite_info data=[0xc0,0x2c] version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_GCM_SHA384 1590664444.197266:qcrypto_tls_cipher_suite_info data=[0xcc,0xa9] version=TLS1.2 name=TLS_ECDHE_ECDSA_CHACHA20_POLY1305 1590664444.197270:qcrypto_tls_cipher_suite_info data=[0xc0,0xad] version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_256_CCM 1590664444.197274:qcrypto_tls_cipher_suite_info data=[0xc0,0x0a] version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_256_CBC_SHA1 1590664444.197278:qcrypto_tls_cipher_suite_info data=[0xc0,0x2b] version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_GCM_SHA256 1590664444.197283:qcrypto_tls_cipher_suite_info data=[0xc0,0xac] version=TLS1.2 name=TLS_ECDHE_ECDSA_AES_128_CCM 1590664444.197287:qcrypto_tls_cipher_suite_info data=[0xc0,0x09] version=TLS1.0 name=TLS_ECDHE_ECDSA_AES_128_CBC_SHA1 1590664444.197291:qcrypto_tls_cipher_suite_info data=[0x00,0x9d] version=TLS1.2 name=TLS_RSA_AES_256_GCM_SHA384 1590664444.197296:qcrypto_tls_cipher_suite_info data=[0xc0,0x9d] version=TLS1.2 name=TLS_RSA_AES_256_CCM 1590664444.197300:qcrypto_tls_cipher_suite_info data=[0x00,0x35] version=TLS1.0 name=TLS_RSA_AES_256_CBC_SHA1 1590664444.197304:qcrypto_tls_cipher_suite_info data=[0x00,0x9c] version=TLS1.2 name=TLS_RSA_AES_128_GCM_SHA256 1590664444.197308:qcrypto_tls_cipher_suite_info data=[0xc0,0x9c] version=TLS1.2 name=TLS_RSA_AES_128_CCM 1590664444.197312:qcrypto_tls_cipher_suite_info data=[0x00,0x2f] version=TLS1.0 name=TLS_RSA_AES_128_CBC_SHA1 1590664444.197316:qcrypto_tls_cipher_suite_info data=[0x00,0x9f] version=TLS1.2 name=TLS_DHE_RSA_AES_256_GCM_SHA384 1590664444.197320:qcrypto_tls_cipher_suite_info data=[0xcc,0xaa] version=TLS1.2 name=TLS_DHE_RSA_CHACHA20_POLY1305 1590664444.197325:qcrypto_tls_cipher_suite_info data=[0xc0,0x9f] version=TLS1.2 name=TLS_DHE_RSA_AES_256_CCM 1590664444.197329:qcrypto_tls_cipher_suite_info data=[0x00,0x39] version=TLS1.0 name=TLS_DHE_RSA_AES_256_CBC_SHA1 1590664444.197333:qcrypto_tls_cipher_suite_info data=[0x00,0x9e] version=TLS1.2 name=TLS_DHE_RSA_AES_128_GCM_SHA256 1590664444.197337:qcrypto_tls_cipher_suite_info data=[0xc0,0x9e] version=TLS1.2 name=TLS_DHE_RSA_AES_128_CCM 1590664444.197341:qcrypto_tls_cipher_suite_info data=[0x00,0x33] version=TLS1.0 name=TLS_DHE_RSA_AES_128_CBC_SHA1 1590664444.197345:qcrypto_tls_cipher_suite_count count: 29 Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200623172726.21040-6-philmd@redhat.com>
2020-07-03crypto: Add tls-cipher-suites objectPhilippe Mathieu-Daudé
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é <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com> Message-Id: <20200623172726.21040-2-philmd@redhat.com>
2020-06-15crypto: Remove use of GCRYPT_VERSION macro.Richard W.M. Jones
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>
2020-06-15crypto/linux_keyring: add 'secret_keyring' secret object.Alexey Krasikov
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 <alex-krasikov@yandex-team.ru> - Fixed up detection logic default behaviour in configure Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-15crypto/secret: move main logic from 'secret' to 'secret_common'.Alexey Krasikov
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 <alex-krasikov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-15crypto: add "none" random providerMarek Marczykowski-Górecki
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 <marmarek@invisiblethingslab.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-15qom: Drop parameter @errp of object_property_add() & friendsMarkus Armbruster
The only way object_property_add() can fail is when a property with the same name already exists. Since our property names are all hardcoded, failure is a programming error, and the appropriate way to handle it is passing &error_abort. Same for its variants, except for object_property_add_child(), which additionally fails when the child already has a parent. Parentage is also under program control, so this is a programming error, too. We have a bit over 500 callers. Almost half of them pass &error_abort, slightly fewer ignore errors, one test case handles errors, and the remaining few callers pass them to their own callers. The previous few commits demonstrated once again that ignoring programming errors is a bad idea. Of the few ones that pass on errors, several violate the Error API. The Error ** argument must be NULL, &error_abort, &error_fatal, or a pointer to a variable containing NULL. Passing an argument of the latter kind twice without clearing it in between is wrong: if the first call sets an error, it no longer points to NULL for the second call. ich9_pm_add_properties(), sparc32_ledma_realize(), sparc32_dma_realize(), xilinx_axidma_realize(), xilinx_enet_realize() are wrong that way. When the one appropriate choice of argument is &error_abort, letting users pick the argument is a bad idea. Drop parameter @errp and assert the preconditions instead. There's one exception to "duplicate property name is a programming error": the way object_property_add() implements the magic (and undocumented) "automatic arrayification". Don't drop @errp there. Instead, rename object_property_add() to object_property_try_add(), and add the obvious wrapper object_property_add(). Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20200505152926.18877-15-armbru@redhat.com> [Two semantic rebase conflicts resolved]
2020-05-07crypto: Redundant type conversion for AES_KEY pointerChen Qun
We can delete the redundant type conversion if we set the the AES_KEY parameter with 'const' in qcrypto_cipher_aes_ecb_(en|de)crypt() function. Reported-by: Euler Robot <euler.robot@huawei.com> Signed-off-by: Chen Qun <kuhn.chenqun@huawei.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-07crypto/secret: fix inconsequential errors.Alexey Krasikov
Change condition from QCRYPTO_SECRET_FORMAT_RAW to QCRYPTO_SECRET_FORMAT_BASE64 in if-operator, because this is potential error if you add another format value. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Alexey Krasikov <alex-krasikov@yandex-team.ru> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-05-07crypto: fix getter of a QCryptoSecret's propertyTong Ho
This fixes the condition-check done by the "loaded" property getter, such that the property returns true even when the secret is loaded by the 'file' option. Signed-off-by: Tong Ho <tong.ho@xilinx.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-03-11luks: extract qcrypto_block_calculate_payload_offset()Stefan Hajnoczi
The qcow2 .bdrv_measure() code calculates the crypto payload offset. This logic really belongs in crypto/block.c where it can be reused by other image formats. The "luks" block driver will need this same logic in order to implement .bdrv_measure(), so extract the qcrypto_block_calculate_payload_offset() function now. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Message-Id: <20200221112522.1497712-2-stefanha@redhat.com> Signed-off-by: Max Reitz <mreitz@redhat.com>
2019-12-20Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into stagingPeter Maydell
* More uses of RCU_READ_LOCK_GUARD (Dave, myself) * QOM doc improvments (Greg) * Cleanups from the Meson conversion (Marc-André) * Support for multiple -accel options (myself) * Many x86 machine cleanup (Philippe, myself) * tests/migration-test cleanup (Juan) * PC machine removal and next round of deprecation (Thomas) * kernel-doc integration (Peter, myself) # gpg: Signature made Wed 18 Dec 2019 01:35:02 GMT # gpg: using RSA key BFFBD25F78C7AE83 # gpg: Good signature from "Paolo Bonzini <bonzini@gnu.org>" [full] # gpg: aka "Paolo Bonzini <pbonzini@redhat.com>" [full] # Primary key fingerprint: 46F5 9FBD 57D6 12E7 BFD4 E2F7 7E15 100C CD36 69B1 # Subkey fingerprint: F133 3857 4B66 2389 866C 7682 BFFB D25F 78C7 AE83 * remotes/bonzini/tags/for-upstream: (87 commits) vga: cleanup mapping of VRAM for non-PCI VGA hw/display: Remove "rombar" hack from vga-pci and vmware_vga hw/pci: Remove the "command_serr_enable" property hw/audio: Remove the "use_broken_id" hack from the AC97 device hw/i386: Remove the deprecated machines 0.12 up to 0.15 hw/pci-host: Add Kconfig entry to select the IGD Passthrough Host Bridge hw/pci-host/i440fx: Extract the IGD passthrough host bridge device hw/pci-host/i440fx: Use definitions instead of magic values hw/pci-host/i440fx: Use size_t to iterate over ARRAY_SIZE() hw/pci-host/i440fx: Extract PCII440FXState to "hw/pci-host/i440fx.h" hw/pci-host/i440fx: Correct the header description Fix some comment spelling errors. target/i386: remove unused pci-assign codes WHPX: refactor load library migration: check length directly to make sure the range is aligned memory: include MemoryListener documentation and some missing function parameters docs: add memory API reference memory.h: Silence kernel-doc complaints docs: Create bitops.rst as example of kernel-docs bitops.h: Silence kernel-doc complaints ... Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2019-12-18crypto: Fix certificate file error handling crash bugMarkus Armbruster
qcrypto_tls_creds_load_cert() passes uninitialized GError *gerr by reference to g_file_get_contents(). When g_file_get_contents() fails, it'll try to set a GError. Unless @gerr is null by dumb luck, this logs a ERROR_OVERWRITTEN_WARNING warning message and leaves @gerr unchanged. qcrypto_tls_creds_load_cert() then dereferences the uninitialized @gerr. Fix by initializing @gerr properly. Fixes: 9a2fd4347c40321f5cbb4ab4220e759fcbf87d03 Cc: "Daniel P. Berrangé" <berrange@redhat.com> Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20191204093625.14836-2-armbru@redhat.com> Acked-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
2019-12-17stubs: replace stubs with lnot if applicablePaolo Bonzini
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 <pbonzini@redhat.com>
2019-12-17crypto: move common bits for all emulators to libqemuutilPaolo Bonzini
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 <pbonzini@redhat.com>
2019-10-28crypto: add support for nettle's native XTS implDaniel P. Berrangé
Nettle 3.5.0 will add 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. Unfortunately this degrades nettle performance from 612 MB/s to 568 MB/s as nettle's XTS impl isn't so well optimized yet. Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-10-28crypto: add support for gcrypt's native XTS implDaniel P. Berrangé
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é <philmd@redhat.com> Reviewed-by: Stefano Garzarella <sgarzare@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: more rigorous header checkingMaxim Levitsky
Check that keyslots don't overlap with the data, and check that keyslots don't overlap with each other. (this is done using naive O(n^2) nested loops, but since there are just 8 keyslots, this doesn't really matter. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: simplify the math used for keyslot locationsMaxim Levitsky
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: extract store key functionMaxim Levitsky
This function will be used later to store new keys to the luks metadata Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: extract check and parse headerMaxim Levitsky
This is just to make qcrypto_block_luks_open more reasonable in size. Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: extract store and load headerMaxim Levitsky
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: purge unused error codes from open callbackMaxim Levitsky
These values are not used by generic crypto code anyway Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: use the parsed encryption settings in QCryptoBlockLUKSMaxim Levitsky
Prior to that patch, the parsed encryption settings were already stored into the QCryptoBlockLUKS but not used anywhere but in qcrypto_block_luks_get_info Using them simplifies the code Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: pass keyslot index rather that pointer to the keyslotMaxim Levitsky
Another minor refactoring Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: simplify masterkey and masterkey lengthMaxim Levitsky
Let the caller allocate masterkey Always use master key len from the header Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: don't overwrite cipher_mode in headerMaxim Levitsky
This way we can store the header we loaded, which will be used in key management code Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-26qcrypto-luks: rename some fields in QCryptoBlockLUKSHeaderMaxim Levitsky
* key_bytes -> master_key_len * payload_offset = payload_offset_sector (to emphasise that this isn't byte offset) * key_offset -> key_offset_sector - same as above for luks slots Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-22crypto: use auto cleanup for many stack variablesDaniel P. Berrangé
Simplify cleanup paths by using glib's auto cleanup macros for stack variables, allowing several goto jumps / labels to be eliminated. Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-08-22glib: bump min required glib library version to 2.48Daniel P. Berrangé
Per supported platforms doc[1], the various min glib on relevant distros is: RHEL-8: 2.56.1 RHEL-7: 2.50.3 Debian (Buster): 2.58.3 Debian (Stretch): 2.50.3 OpenBSD (Ports): 2.58.3 FreeBSD (Ports): 2.56.3 OpenSUSE Leap 15: 2.54.3 SLE12-SP2: 2.48.2 Ubuntu (Xenial): 2.48.0 macOS (Homebrew): 2.56.0 This suggests that a minimum glib of 2.48 is a reasonable target. Compared to the previous version bump in commit e7b3af81597db1a6b55f2c15d030d703c6b2c6ac Author: Daniel P. Berrangé <berrange@redhat.com> Date: Fri May 4 15:34:46 2018 +0100 glib: bump min required glib library version to 2.40 This will result in us dropping support for Debian Jessie and Ubuntu 14.04. As per the commit message 14.04 was already outside our list of supported build platforms and an exception was only made because one of the build hosts used during merge testing was stuck on 14.04. Debian Jessie is justified to drop because we only aim to support at most 2 major versions of Debian at any time. This means Buster and Stretch at this time. The g_strv_contains compat code is dropped as this API is present since 2.44 The g_assert_cmpmem compat code is dropped as this API is present since 2.46 [1] https://qemu.weilnetz.de/doc/qemu-doc.html#Supported-build-platforms Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-19crypto: Fix LGPL information in the file headersThomas Huth
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>
2019-07-19crypto: fix function signatures for nettle 2.7 vs 3Daniel P. Berrangé
Nettle version 2.7.x used 'unsigned int' instead of 'size_t' for length parameters in functions. Use a local typedef so that we can build with the correct signature depending on nettle version, as we already do in the cipher code. Reported-by: Amol Surati <suratiamol@gmail.com> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-19crypto: switch to modern nettle AES APIsDaniel P. Berrangé
The aes_ctx struct and aes_* functions have been deprecated in nettle 3.5, in favour of keysize specific functions which were introduced first in nettle 3.0. Switch QEMU code to use the new APIs and add some backcompat defines such that it still builds on nettle 2.7 Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-06-12Normalize position of header guardMarkus Armbruster
This is the common header guard idiom: /* * File comment */ #ifndef GUARD_SYMBOL_H #define GUARD_SYMBOL_H ... actual contents ... #endif A few of our headers have some #include before the guard. target/tilegx/spr_def_64.h has #ifndef __DOXYGEN__ outside the guard. A few more have the #define elsewhere. Change them to match the common idiom. For spr_def_64.h, that means dropping #ifndef __DOXYGEN__. While there, rename guard symbols to make scripts/clean-header-guards.pl happy. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190604181618.19980-2-armbru@redhat.com> [Rebased with conflicts resolved automatically]
2019-06-12Include qemu-common.h exactly where neededMarkus Armbruster
No header includes qemu-common.h after this commit, as prescribed by qemu-common.h's file comment. Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-5-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for include/hw/arm/xlnx-zynqmp.h hw/arm/nrf51_soc.c hw/arm/msf2-soc.c block/qcow2-refcount.c block/qcow2-cluster.c block/qcow2-cache.c target/arm/cpu.h target/lm32/cpu.h target/m68k/cpu.h target/mips/cpu.h target/moxie/cpu.h target/nios2/cpu.h target/openrisc/cpu.h target/riscv/cpu.h target/tilegx/cpu.h target/tricore/cpu.h target/unicore32/cpu.h target/xtensa/cpu.h; bsd-user/main.c and net/tap-bsd.c fixed up]
2019-06-12Include qemu/module.h where needed, drop it from qemu-common.hMarkus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Message-Id: <20190523143508.25387-4-armbru@redhat.com> [Rebased with conflicts resolved automatically, except for hw/usb/dev-hub.c hw/misc/exynos4210_rng.c hw/misc/bcm2835_rng.c hw/misc/aspeed_scu.c hw/display/virtio-vga.c hw/arm/stm32f205_soc.c; ui/cocoa.m fixed up]
2019-05-22crypto: Change the qcrypto_random_bytes buffer type to void*Richard Henderson
Using uint8_t* merely requires useless casts for use with other types to be filled with randomness. Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-05-22crypto: Use getrandom for qcrypto_random_bytesRichard Henderson
Prefer it to direct use of /dev/urandom. Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-05-22crypto: Use O_CLOEXEC in qcrypto_random_initRichard Henderson
Avoids leaking the /dev/urandom fd into any child processes. Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-05-22crypto: Do not fail for EINTR during qcrypto_random_bytesRichard Henderson
We can always get EINTR for read; /dev/urandom is no exception. Rearrange the order of tests for likelihood; allow degenerate buflen==0 case to perform a no-op zero-length read. This means that the normal success path is a straight line with a single test for success. Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-05-22crypto: Reverse code blocks in random-platform.cRichard Henderson
Use #ifdef _WIN32 instead of #ifndef _WIN32. This will make other tests easier to sequence. Reviewed-by: Laurent Vivier <lvivier@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-05-22build: Link user-only with crypto random number objectsRichard Henderson
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é <berrange@redhat.com> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
2019-03-22trace-events: Shorten file names in commentsMarkus Armbruster
We spell out sub/dir/ in sub/dir/trace-events' comments pointing to source files. That's because when trace-events got split up, the comments were moved verbatim. Delete the sub/dir/ part from these comments. Gets rid of several misspellings. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Message-id: 20190314180929.27722-3-armbru@redhat.com Message-Id: <20190314180929.27722-3-armbru@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>