On Fri, Sep 19, 2014 at 1:21 PM, Nadav Amit <[email protected]> wrote:
>
> On Sep 19, 2014, at 9:42 PM, Andy Lutomirski <[email protected]> wrote:
>
>> On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
>> <[email protected]> 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
--
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

Reply via email to