Re: [Qemu-devel] [PATCH for-4.1 0/7] Add qemu_getrandom and ARMv8.5-RNG

[Daniel P . Berrangé]

On Wed, Mar 13, 2019 at 11:35:33AM -0700, Richard Henderson wrote:
> On 3/13/19 10:57 AM, Daniel P. Berrangé wrote:
> > We already have an internal API for providing strong random bytes in
> > QEMU qcrypto_random_bytes. It is preferentially backed by gnutls or
> > gcrypt, but if those aren't built-in it falls back to a platform
> > native API like /dev/random. I've got a todo item to make that use
> > getrandom on Linux/BSD when available.
> > 
> > I don't think we should be adding a new APIs for getting random
> > numbers that aren't backed by the qcrypto_random_bytes.
> 
> That's all very well and good for one particular use case, when we really want
> random numbers.  But with -seed, we want to be able to replicate one 
> particular
> execution, with fully deterministic numbers.
>
> But certainly I can look into making the non-deterministic execution use your
> existing interface.  I simply wasn't aware of it.

The random interfact is pluggable with different impls though they are
chosen at build time currently. I guess we could provide an impl that
is backed by a deterministic source and require a special CLI option or
env var to switch to this insecure mode at runtime.

> Do you happen to know off-hand the maximum latency of the gnutls/gcrypt
> interfaces?  I do want the interface to be able to return "timed-out" in
> certain cases.  With getrandom(2) there is a handy GRND_NONBLOCK parameter 
> that
> pretty much matches exactly what I want.  With /dev/{u,}random, one would have
> to use O_NONBLOCK.  With BSD getentropy, I think you'd need an alarm to time
> out the operation (unless EIO covers all sorts of failures like empty entropy
> pool; the manual isn't clear)?

I don't think there's any documented latency rules for the library
interfaces. Most of the time I think they should have deterministic
execution time as they'll just be running a cryptographic hash
algorithm of some kind, but they might periodically re-seed entropy
from the host OS. They're really supposed to be considered a black
box from the application user POV.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|