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 :|
