On 06/08/15 13:26, Laurent Vivier wrote: > Hi, > > As "/dev/random" can be blocking perhaps it is possible/better to use > the QEMU rng backend instead ?
Actually, I tried to use the rng backends first ... but they turned out to be horrible for being used in a synchronous call like I need here: You've got to install a callback function which is called at a "random" point in time when some data becomes available - and it is even called with less bytes than you requested! (i.e. I requested 8 bytes, but the callback got only called with 6 bytes). So to use it, I'd have to introduce a ring buffer or something similar to query enough random data in advance - and when it runs empty, the H_RANDOM hypercall would need to block again anyway. So instead of introducing a hard-to-understand-and-maintain "monster wrapper" around the rng backend functions, I think the short and easy understandable qemu_random() implementation in this patch here is the better choice. And looking at https://patchwork.ozlabs.org/patch/497062/ I think it also should not hurt too much that qemu_random() might be slow here since the real hardware number generator is apparently also not very fast. Thomas > On 06/08/2015 10:23, Thomas Huth wrote: >> The spapr firmware SLOF likely needs a way to get random numbers >> soon. Instead of re-inventing the wheel there, we could simply >> use the H_RANDOM hypercall to get the random numbers from QEMU. >> For this the H_RANDOM hypercall needs to be implemented first, of >> course. >> So this patch introduces an OS-specifc helper function called >> qemu_random() to get "good" random numbers (from /dev/random on >> POSIX systems and via CryptGenRandom() on Windows), and then uses >> this helper functions to provide random data to the guest via the >> H_RANDOM hypercall. >> >> Signed-off-by: Thomas Huth <th...@redhat.com> >> --- >> Note: Since I do not have access to the SPAPR spec, I figured out >> the calling conventions of the hypercall by looking at the way >> the Linux kernel is using this call to retriev random data. So >> there might be some bugs or missing pieces here. >> >> Also note that the Windows version of qemu_random() is >> compile-tested only (with a MinGW cross-compiler), since I do not >> have access to a Windows system right now. >> >> hw/ppc/spapr_hcall.c | 12 ++++++++++++ >> include/hw/ppc/spapr.h | 1 + >> include/qemu/osdep.h | 11 +++++++++++ >> util/oslib-posix.c | 16 ++++++++++++++++ >> util/oslib-win32.c | 17 +++++++++++++++++ >> 5 files changed, 57 insertions(+)