On 5/7/19 10:22 AM, Daniel P. Berrangé wrote: > On Tue, May 07, 2019 at 11:59:05AM +0200, Nikos Mavrogiannopoulos wrote: >> In terms of RHEL what is preferred is (1) use a crypto lib, and (2) if >> that's not possible use getrandom(). That is summarized in this >> article: >> >> https://www.redhat.com/en/blog/understanding-red-hat-enterprise-linux-random-number-generator-interface > > For QEMU this would mean re-writing the code to use qcrypto_random_bytes > instead. This internal API is backed by a crypto lib if available, > falling back to /dev/urandom or /dev/random on UNIX, or CryptGenRandom > on Windows. We could add getrandom() support there too. > > The main question is whether to implement a new backends/rng-builtin.c > or modify backends/rng-random.c so that it has a NULL filename by > default, which would be taken as meaning use the qcrypto_random_bytes > API. The latter benefits that all existing VMs which don't have a > filename set would get the new behaviour. The latter has downside > that it is not discoverable from mgmt apps, so they won't know if > they can rely on it or not.
Alas, our example in misc.json is:
# -> { "execute": "object-add",
# "arguments": { "qom-type": "rng-random", "id": "rng1",
# "props": { "filename": "/dev/hwrng" } } }
# <- { "return": {} }
which is indeed one of the interfaces that evades introspection at the
present, so even if we made filename a StrOrNull, which would normally
show up in introspection when done on any other command, it is invisible
here. :(
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
