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>
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]
- 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/704724619https://gitlab.com/philmd/qemu/-/pipelines/162938106https://cirrus-ci.com/build/4682977303068672
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+qvnXhKRciHc/Wuy4+MsLN6twN4FAl8AsDQACgkQ4+MsLN6t
wN4HLA//Sxi7iYWp3OygX1F7A9XpWxuWNVjThBJzao00y0qxWQ7G6l/YTDeNYOoD
dE/HsyUd3QtvC6/c79zoqyOb5m+WtQNsQmHAO4LZdR16TPNvTdCZ2lNgWYRIjuHJ
obvYy2ingKpnlzd5V1bioTlUw0AOchk86pMnTVAsoKPXWqsOrPB+PYmE9tFRxqVY
5WVW7rnhtcJ05ajeIWhgndhW7fM4lvoWdZyctTIhWttQ9WkhyKAYKHQrmgOcsbUp
soOfK9oHRH1XuUsC0SHpPmUQbp/c5cyCS1D7nDuIe/lPNNfWCVeUKkny495Vgj4d
nK6MI1PQ4Bw2VBfMMxO4dXl2rnzlVjSnXXUP56IdfZHlOr+5gPh7uZvfZXN3AmHC
km9MBt2IWrDYAriMwHhqumzHMIFmNVdqdXaYZYzagwwFzy8VNLgzQEFQYHsIXtl3
7pfvZVtIbSfXFGfktY3vu4sBZNAAk3mAOc04faF3CuTvXp5m0Duc0boO38eLDCbp
5mV2uEUJ9zQzcSoLqfLGiYCBFX9C8XdjdX+u9gMHhNb04y5c6r/zZZKpH7ZfwEc1
WdwXzEor+h3yW06dV1WdOGlMUqVt3Xx9GaJBW57XbdMQQ2O2m+TfMcYLeVLsXtvf
aHUKOZdBxRKFcbA7zARhZ4xyzNQVddz3+aTGpzpP/xIL4TXrzHQ=
=QArU
-----END PGP SIGNATURE-----
Merge remote-tracking branch 'remotes/philmd-gitlab/tags/fw_cfg-20200704' 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/704724619https://gitlab.com/philmd/qemu/-/pipelines/162938106https://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>
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>
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>
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>
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>
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>
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>
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>
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]
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>
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>
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>
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>
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: 9a2fd4347c
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
* 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>
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>
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 e7b3af8159
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>
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>
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>
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>
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]
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]
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>
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>
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>
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>
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>
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>
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>
Build fails with gcc 9:
crypto/block-luks.c:689:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
689 | be32_to_cpus(&luks->header.payload_offset);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
crypto/block-luks.c:690:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
690 | be32_to_cpus(&luks->header.key_bytes);
| ^~~~~~~~~~~~~~~~~~~~~~~
crypto/block-luks.c:691:18: error: taking address of packed member of ‘struct QCryptoBlockLUKSHeader’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
691 | be32_to_cpus(&luks->header.master_key_iterations);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
... a bunch of similar errors...
crypto/block-luks.c:1288:22: error: taking address of packed member of ‘struct QCryptoBlockLUKSKeySlot’ may result in an unaligned pointer value [-Werror=address-of-packed-member]
1288 | be32_to_cpus(&luks->header.key_slots[i].stripes);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
All members of the QCryptoBlockLUKSKeySlot and QCryptoBlockLUKSHeader are
naturally aligned and we already check at build time there isn't any
unwanted padding. Drop the QEMU_PACKED attribute.
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Greg Kurz <groug@kaod.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The 'qemu_acl' type was a previous non-QOM based attempt to provide an
authorization facility in QEMU. Because it is non-QOM based it cannot be
created via the command line and requires special monitor commands to
manipulate it.
The new QAuthZ subclasses provide a superset of the functionality in
qemu_acl, so the latter can now be deleted. The HMP 'acl_*' monitor
commands are converted to use the new QAuthZSimple data type instead
in order to provide temporary backwards compatibility.
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Tested-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
