Re: [Qemu-devel] [RFC] Virtio RNG: Consider changing the default entropy source to /dev/urandom?

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1720 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]