summaryrefslogtreecommitdiff
path: root/backends/rng-random.c
AgeCommit message (Collapse)Author
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]
2019-07-03VirtIO-RNG: Update default entropy source to `/dev/urandom`Kashyap Chamarthy
When QEMU exposes a VirtIO-RNG device to the guest, that device needs a source of entropy, and that source needs to be "non-blocking", like `/dev/urandom`. However, currently QEMU defaults to the problematic `/dev/random`, which on Linux is "blocking" (as in, it waits until sufficient entropy is available). Why prefer `/dev/urandom` over `/dev/random`? --------------------------------------------- The man pages of urandom(4) and random(4) state: "The /dev/random device is a legacy interface which dates back to a time where the cryptographic primitives used in the implementation of /dev/urandom were not widely trusted. It will return random bytes only within the estimated number of bits of fresh noise in the entropy pool, blocking if necessary. /dev/random is suitable for applications that need high quality randomness, and can afford indeterminate delays." Further, the "Usage" section of the said man pages state: "The /dev/random interface is considered a legacy interface, and /dev/urandom is preferred and sufficient in all use cases, with the exception of applications which require randomness during early boot time; for these applications, getrandom(2) must be used instead, because it will block until the entropy pool is initialized. "If a seed file is saved across reboots as recommended below (all major Linux distributions have done this since 2000 at least), the output is cryptographically secure against attackers without local root access as soon as it is reloaded in the boot sequence, and perfectly adequate for network encryption session keys. Since reads from /dev/random may block, users will usually want to open it in nonblocking mode (or perform a read with timeout), and provide some sort of user notification if the desired entropy is not immediately available." And refer to random(7) for a comparison of `/dev/random` and `/dev/urandom`. What about other OSes? ---------------------- `/dev/urandom` exists and works on OS-X, FreeBSD, DragonFlyBSD, NetBSD and OpenBSD, which cover all the non-Linux platforms we explicitly support, aside from Windows. On Windows `/dev/random` doesn't work either so we don't regress. This is actually another argument in favour of using the newly proposed 'rng-builtin' backend by default, as that will work on Windows. - - - Given the above, change the entropy source for VirtIO-RNG device to `/dev/urandom`. Related discussion in these[1][2] past threads. [1] https://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg08335.html -- "RNG: Any reason QEMU doesn't default to `/dev/urandom`?" [2] https://lists.nongnu.org/archive/html/qemu-devel/2018-09/msg02724.html -- "[RFC] Virtio RNG: Consider changing the default entropy source to /dev/urandom" Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Laurent Vivier <lvivier@redhat.com> Message-Id: <20190529143106.11789-2-lvivier@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
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]
2016-05-23rng-random: rename RndRandom to RngRandomWei Jiangang
Usually, Random Number Generator is abbreviated to RNG/rng. so replacing RndRandom with RngRandom seems more reasonable and keep consistent with RngBackend. Signed-off-by: Wei Jiangang <weijg.fnst@cn.fujitsu.com> Reviewed-by: Pankaj Gupta <pagupta@redhat.com> Message-Id: <1460684168-5403-1-git-send-email-weijg.fnst@cn.fujitsu.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-03-22include/qemu/osdep.h: Don't include qapi/error.hMarkus Armbruster
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>
2016-03-08rng: switch request queue to QSIMPLEQLadi Prosek
QSIMPLEQ supports appending to tail in O(1) and is intrusive so it doesn't require extra memory allocations for the bookkeeping data. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Message-Id: <1457010971-24771-1-git-send-email-lprosek@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-03-03rng: add request queue support to rng-randomLadi Prosek
Requests are now created in the RngBackend parent class and the code path is shared by both rng-egd and rng-random. This commit fixes the rng-random implementation which processed only one request at a time and simply discarded all but the most recent one. In the guest this manifested as delayed completion of reads from virtio-rng, i.e. a read was completed only after another read was issued. By switching rng-random to use the same request queue as rng-egd, the unsafe stack-based allocation of the entropy buffer is eliminated and replaced with g_malloc. Signed-off-by: Ladi Prosek <lprosek@redhat.com> Reviewed-by: Amit Shah <amit.shah@redhat.com> Message-Id: <1456994238-9585-5-git-send-email-lprosek@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com>
2016-02-04backends: Clean up includesPeter Maydell
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: 1454089805-5470-5-git-send-email-peter.maydell@linaro.org
2015-06-22qerror: Clean up QERR_ macros to expand into a single stringMarkus Armbruster
These macros expand into error class enumeration constant, comma, string. Unclean. Has been that way since commit 13f59ae. The error class is always ERROR_CLASS_GENERIC_ERROR since the previous commit. Clean up as follows: * Prepend every use of a QERR_ macro by ERROR_CLASS_GENERIC_ERROR, and delete it from the QERR_ macro. No change after preprocessing. * Rewrite error_set(ERROR_CLASS_GENERIC_ERROR, ...) into error_setg(...). Again, no change after preprocessing. Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Luiz Capitulino <lcapitulino@redhat.com>
2014-12-10Drop superfluous conditionals around g_strdup()Markus Armbruster
Signed-off-by: Markus Armbruster <armbru@redhat.com> Reviewed-by: Fam Zheng <famz@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2014-06-24rng-random: NULL check not needed before g_free()Eduardo Habkost
g_free() is NULL-safe. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2014-01-06rng: initialize file descriptor to -1Paolo Bonzini
The file descriptor is never initialized to -1, which makes rng-random close stdin if an object is created and immediately destroyed. If we change it to -1, we also need to protect qemu_set_fd_handler from receiving a bogus file descriptor. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Tested-by: Igor Mammedov <imammedo@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2013-06-17rng-random: use error_setg_file_open()Luiz Capitulino
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Acked-by: Kevin Wolf <kwolf@redhat.com>
2013-04-16rng random backend: check for -EAGAIN errors on readAmit Shah
Not handling EAGAIN triggers the assert qemu/backends/rng-random.c:44:entropy_available: assertion failed: (len != -1) Aborted (core dumped) This happens when starting a guest with '-device virtio-rng-pci', issuing a 'cat /dev/hwrng' in the guest, while also doing 'cat /dev/random' on the host. Reported-by: yunpingzheng <yunzheng@redhat.com> Signed-off-by: Amit Shah <amit.shah@redhat.com> Message-id: eacda84dfaf2d99cf6d250b678be4e4d6c2088fb.1366108096.git.amit.shah@redhat.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-04-15sysemu: avoid proliferation of include/ subdirectoriesPaolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2013-03-08rng-random: Use qemu_open / qemu_closeStefan Berger
In the rng backend use qemu_open and qemu_close rather than POSIX open/close. Signed-off-by: Stefan Berger <stefanb@linux.vnet.ibm.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2013-01-10Make all static TypeInfos constAndreas Färber
Since 39bffca2030950ef6efe57c2fac8327a45ae1015 (qdev: register all types natively through QEMU Object Model), TypeInfo as used in the common, non-iterative pattern is no longer amended with information and should therefore be const. Fix the documented QOM examples: sed -i 's/static TypeInfo/static const TypeInfo/g' include/qom/object.h Since frequently the wrong examples are being copied by contributors of new devices, fix all types in the tree: sed -i 's/^static TypeInfo/static const TypeInfo/g' */*.c sed -i 's/^static TypeInfo/static const TypeInfo/g' */*/*.c This also avoids to piggy-back these changes onto real functional changes or other refactorings. Signed-off-by: Andreas Färber <afaerber@suse.de> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2012-12-19misc: move include files to include/qemu/Paolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-12-19qapi: move include files to include/qobject/Paolo Bonzini
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2012-11-16rng-random: add an RNG backend that uses /dev/random (v3)Anthony Liguori
The filename can be overridden but it expects a non-blocking source of entropy. A typical invocation would be: qemu -object rng-random,id=rng0 -device virtio-rng-pci,rng=rng0 This can also be used with /dev/urandom by using the command line: qemu -object rng-random,filename=/dev/urandom,id=rng0 \ -device virtio-rng-pci,rng=rng0 Signed-off-by: Anthony Liguori <aliguori@us.ibm.com> --- v1 -> v2 - merged header split patch into this one v2 -> v3 - bug fix in rng-random (Paolo)