On 5/7/19 8: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.
At least this last step is done: https://patchwork.ozlabs.org/patch/1056828/ > 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. > > Thus I'd probably tend towards a new backend for discoverability. What does it mean to rely on the filename, really? We could special case "/dev/urandom" as qcrypto_random_bytes, which would end up using getrandom(2) or /dev/urandom via the crypto lib anyway. We could even special case "/dev/random" as getrandom(2) w/GRND_RANDOM, if we cared to bypass the crypto lib. Only oddballs like "/dev/myhwrng" truly need to go through the filesystem interface in order to preserve behaviour, I would think. r~
