Virtualization - Sep 2014 - Standardizing an MSR or other hypercall to get an RNG seed?

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 at mit.edu>
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?

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?

     	     	       	    	       	       - Ted

On Fri, Sep 19, 2014 at 3:57 PM, Theodore Ts'o <tytso at mit.edu>
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 at
mit.edu> 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

On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
> 
> 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.
> 
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.

	-hpa

On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
> 
> 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.
> 
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.

	-hpa