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~