Re: Standardizing an MSR or other hypercall to get an RNG seed?

[Andy Lutomirski <luto@amacapital.net>]

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