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.
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)?
r~
