On Thu, Sep 18, 2014 at 11:54 AM, Niels Ferguson <[email protected]> wrote: > Defining a standard way of transferring random numbers between the host and > the guest is an excellent idea. > > As the person who writes the RNG code in Windows, I have a few comments: > > DETECTION: > It should be possible to detect this feature through CPUID or similar > mechanism. That allows the code that uses this feature to be written without > needing the ability to catch CPU exceptions. I could be wrong, but as far as > I know there is no support for exception handling in the Windows OS loader > where we gather our initial random state. >
Linux is like this, too, except that I have experimental code to create an IDT in that code, so we can handle it. I agree, though, that using CPUID in early boot is easier. > EFFICIENCY: > Is there a way we can transfer more bytes per interaction? With a single > 64-bit MSR we always need multiple reads to get a seed, and each of them > results in a context switch to the host, which is expensive. This is even > worse for 32-bit guests. Windows would typically need to fetch 64 bytes of > random data at boot and at regular intervals. It is not a show-stopper, but > better efficiency would be nice. I thought about this for a while and didn't come up with anything that wouldn't messy. We could fudge the MSR rax/rdx high bits to get 128 bits, but that's nonportable and awful to implement. We could return a random number directly from CPUID, but that's weird. In very informal benchmarking, rdmsr wasn't that bad. On the other hand, I wasn't immediately planning on using the msr on an ongoing basis on Linux guests except after suspend/resume. > > GUEST-TO-HOST: > Can we also define a way to have random values flow from the guest to the > host? Guests are also gathering entropy from their own sources, and if we > allow the guests to send random data to the host, then the host can treat it > as an entropy source and all the VMs on a single host can share their > entropy. (This is not a security problem; any reasonable host RNG cannot be > hurt even by maliciously chosen entropy inputs.) > wrmsr on the same MSR? > > I don't know much about how hypervisors work on the inside, but maybe we can > define a mechanism for standardized hypervisor calls that work on all > hypervisors that support this feature. Then we could define a function to do > an entropy exchange: the guest provides N bytes of random data to the host, > and the host replies with N bytes of random data. The data exchange can now > be done through memory. > > A standardized hypervisor-call mechanism also seems generally useful for > future features, whereas the MSR solution is very limited in what it can do. > We might end up with standardized hypervisor-calls in the future for some > other reason, and then the MSR solution looks very odd. I think there'll be resistance to a standardized hypercall mechanism, just because the implementations tend to be complex. Hyper-V uses a special page in guest physical memory that contains a trampoline. We could use wrmsr to a register where the payload is a pointer to a buffer to receive random bytes, but that loses some of the simplicity of just calling rdmsr a few times. --Andy -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
