On Thu, May 1, 2014 at 1:39 PM, <tytso@xxxxxxx> wrote: > On Thu, May 01, 2014 at 01:32:55PM -0700, Andy Lutomirski wrote: >> On Thu, May 1, 2014 at 1:30 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: >> > RDSEED is not synchronous. It is, however, nonblocking. >> >> What I mean is: IIUC it's reasonable to call RDSEED a few times in a >> loop and hope it works. It makes no sense to do that with >> /dev/random. > > RDSEED is allowed to return an error if there is insufficient entropy. > So long as the caller understands that this is an emulated > instruction, I don't see a problem. What's the point? I think this is too caught up in x86 architectural stuff. As I see it, the goal is to give guests a way to ask their hosts to give them, immediately and synchronously, some bytes suitable for seeding an RNG. These bytes need not contain true entropy, because the host may not be able to provide entropy an a timely manner. The mechanism should be usable extremely early after boot, it should be usable after a guest reboot, and it should be reliable. I think there's an added benefit if all architectures can implement a semantically equivalent function, even if the interface is completely different. There's no need for anything new to provide asynchronous and-or very slow true random data -- virtio-rng already exists. * Emulating RDRAND for this purpose is a little weird because it's normally available to user code and it has the flag indicating failure. We're also not going to want the guest kernel to access it through the arch_get_random interface. Even if we could emulate RDSEED effectively**, I don't really understand what the guest is expected to do with it. And I generally dislike defining an interface with no known sensible users, because it means that there's a good chance that the interface won't end up working. * I still don't know why it doesn't work for me. I'll fiddle with it, but I think that the right solution is to fix it for this purpose, not to replace it. ** Doing this sensibly in the host will be awkward. Is the host supposed to use non-blocking reads of /dev/random? Getting anything remotely fair may be difficult. > > - Ted -- Andy Lutomirski AMA Capital Management, LLC -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
