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

On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
<cov at codeaurora.org> wrote:
> On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
>> Hi all-
>>
>> I would like to standardize on a very simple protocol by which a guest
>> OS can obtain an RNG seed early in boot.
>>
>> The main design requirements are:
>>
>>  - The interface should be very easy to use.  Linux, at least, will
>> want to use it extremely early in boot as part of kernel ASLR.  This
>> means that PCI and ACPI will not work.
>
> How do non-virtual systems get entropy this early? RDRAND/Padlock?
Truerand?
> Could hypervisors and simulators simply make sure these work?
>
If RDRAND is available, then Linux, at least, will use it.  The rest
are too complicated for early use.  Linux on x86 plays some vaguely
clever games with rdtsc and poking at the i8254 port.

I think that these tricks are even less useful as a guest than they
are on metal, and we can use paravirt mechanisms to make guest early
boot rngs much stronger.

--Andy

On Sep 19, 2014, at 9:42 PM, Andy Lutomirski <luto at amacapital.net>
wrote:
> On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
> <cov at codeaurora.org> wrote:
>> On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
>>> Hi all-
>>> 
>>> I would like to standardize on a very simple protocol by which a
guest
>>> OS can obtain an RNG seed early in boot.
>>> 
>>> The main design requirements are:
>>> 
>>> - The interface should be very easy to use.  Linux, at least, will
>>> want to use it extremely early in boot as part of kernel ASLR. 
This
>>> means that PCI and ACPI will not work.
>> 
>> How do non-virtual systems get entropy this early? RDRAND/Padlock?
Truerand?
>> Could hypervisors and simulators simply make sure these work?
>> 
> 
> If RDRAND is available, then Linux, at least, will use it.  The rest
> are too complicated for early use.  Linux on x86 plays some vaguely
> clever games with rdtsc and poking at the i8254 port.
> 
> I think that these tricks are even less useful as a guest than they
> are on metal, and we can use paravirt mechanisms to make guest early
> boot rngs much stronger.
Sorry for interrupting, as I understand the discussion tries to be generic.

However, it sounds to me that at least for KVM, it is very easy just to emulate
the RDRAND instruction. The hypervisor would report to the guest that RDRAND is
supported in CPUID and the emulate the instruction when guest executes it. KVM
already traps guest #UD (which would occur if RDRAND executed while it is not
supported) - so this scheme wouldn?t introduce additional overhead over RDMSR.

Nadav

On Fri, Sep 19, 2014 at 1:21 PM, Nadav Amit <nadav.amit at gmail.com>
wrote:
>
> On Sep 19, 2014, at 9:42 PM, Andy Lutomirski <luto at amacapital.net>
wrote:
>
>> On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
>> <cov at codeaurora.org> wrote:
>>> On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
>>>> Hi all-
>>>>
>>>> I would like to standardize on a very simple protocol by which
a guest
>>>> OS can obtain an RNG seed early in boot.
>>>>
>>>> The main design requirements are:
>>>>
>>>> - The interface should be very easy to use.  Linux, at least,
will
>>>> want to use it extremely early in boot as part of kernel ASLR. 
This
>>>> means that PCI and ACPI will not work.
>>>
>>> How do non-virtual systems get entropy this early? RDRAND/Padlock?
Truerand?
>>> Could hypervisors and simulators simply make sure these work?
>>>
>>
>> If RDRAND is available, then Linux, at least, will use it.  The rest
>> are too complicated for early use.  Linux on x86 plays some vaguely
>> clever games with rdtsc and poking at the i8254 port.
>>
>> I think that these tricks are even less useful as a guest than they
>> are on metal, and we can use paravirt mechanisms to make guest early
>> boot rngs much stronger.
>
> Sorry for interrupting, as I understand the discussion tries to be generic.
>
> However, it sounds to me that at least for KVM, it is very easy just to
emulate the RDRAND instruction. The hypervisor would report to the guest that
RDRAND is supported in CPUID and the emulate the instruction when guest executes
it. KVM already traps guest #UD (which would occur if RDRAND executed while it
is not supported) - so this scheme wouldn?t introduce additional overhead over
RDMSR.
Because then guest user code will think that rdrand is there and will
try to use it, resulting in abysmal performance.

--Andy
>
> Nadav


-- 
Andy Lutomirski
AMA Capital Management, LLC

On 09/19/2014 02:42 PM, Andy Lutomirski wrote:
> On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
> <cov at codeaurora.org> wrote:
>> On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
>>> Hi all-
>>>
>>> I would like to standardize on a very simple protocol by which a
guest
>>> OS can obtain an RNG seed early in boot.
>>>
>>> The main design requirements are:
>>>
>>>  - The interface should be very easy to use.  Linux, at least, will
>>> want to use it extremely early in boot as part of kernel ASLR. 
This
>>> means that PCI and ACPI will not work.
>>
>> How do non-virtual systems get entropy this early? RDRAND/Padlock?
Truerand?
>> Could hypervisors and simulators simply make sure these work?
>>
> 
> If RDRAND is available, then Linux, at least, will use it.  The rest
> are too complicated for early use.  Linux on x86 plays some vaguely
> clever games with rdtsc and poking at the i8254 port.
I just wanted to check that it couldn't be as simple as giving one or both
of
the timers random initial values.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.