On Fri, Sep 19, 2014 at 3:57 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: > On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote: >> On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o <tytso@xxxxxxx> wrote: >> > On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote: >> >> >> >> There is a huge disadvantage to the fact that CPUID is a user space >> >> instruction, though. >> > >> > But if the goal is to provide something like getrandom(2) direct from >> > the Host OS, it's not necessarily harmful to allow the Guest ring 3 >> > code to be able to fetch randomness in that way. The hypervisor can >> > implement rate limiting to protect against the guest using this too >> > frequently, but this is something that you should be doing for guest >> > ring 0 code anyway, since from the POV of the hypervisor Guest ring 0 >> > is not necessarily any more trusted than Guest ring 3. >> >> On the other hand, the guest kernel might not want the guest ring 3 to >> be able to get random numbers. > > Um, why? To force deterministic execution. I incorrectly thought that the kernel could switch RDRAND on and off. It turns out that a hypervisor can do this, but not the kernel. Also, determinism is lost anyway because of TSX, which *also* can't be turned on and off. > > We're talking about using this to seed the RNG, and not something that > the guest kernel would be using continuously. So what's the problem > with letting the guest ring get random numbers from the host? I object to preventing guest kernels from limiting the privileges of their own userspace. Letting guest CPL3 do this is essentially setting guest policy in the hypervisor, which I dislike if we can avoid it. Admittedly, in this case, control of RNG availability in guest userspace may be a lost cause regardless. --Andy -- 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
