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

On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski <luto at amacapital.net>
wrote:
> On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski <luto at
amacapital.net> wrote:
>> On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun <jun.nakajima at
intel.com> wrote:
>>> On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski <luto at
amacapital.net> wrote:
>>>
>>>> So, as a concrete straw-man:
>>>>
>>>> CPUID leaf 0x48000000 would return a maximum leaf number in EAX
(e.g.
>>>> 0x48000001) along with a signature value (e.g.
"CrossHVPara\0") in
>>>> EBX, ECX, and EDX.
>>>>
>>>> CPUID 0x48000001.EAX would contain an MSR number to read to get
a
>>>> random number if supported and zero if not supported.
>>>>
>>>> Questions:
>>>>
>>>> 1. Can we use a fixed MSR number?  This would be a little bit
simpler,
>>>> but it would depend on getting a wider MSR range from Intel.
>>>>
>>>
>>> Why do you need a wider MSR range if you always detect the feature
by
>>> CPUID.0x48000001?
>>> Or are you still trying to avoid the detection by CPUID?
>>
>> Detecting the feature is one thing, but figuring out the MSR index is
>> another.  We could shove the index into the cpuid leaf, but that seems
>> unnecessarily indirect.  I'd much rather just say that CPUID leaves
>> *and* MSR indexes 0x48000000-0x4800ffff or so are reserved for the
>> cross-HV mechanism, but we can't do that without either knowingly
>> violating the SDM assignments or asking Intel to consider allocating
>> more MSR indexes.
>>
>> Also, KVM is already conflicting with the SDM right now in its MSR
>> choice :(  I *think* that KVM could be changed to fix that, but 256
>> MSRs is rather confining given that KVM currently implements its own
>> MSR index *and* part of the Hyper-V index.
>
> Correction and update:
>
> KVM currently implements its own MSRs and, optionally, some of the
> Hyper-V MSRs.  By my count, Linux knows about 68 Hyper-V MSRs (in a
> header file), and there are current 7 KVM MSRs, so over 1/4 of the
> available MSR indices are taken (and even more would be taken if KVM
> were to move its MSRs into the correct range).
>
I slept on it, and I think using the CPUID instruction alone would be
simple and efficient:
- We have a huge space for CPUID leaves
- CPUID also works for user-level
- It can take an additional 32-bit parameter (ECX), and returns 4
32-bit values (EAX, EBX, ECX, and EDX).  RDMSR, for example, returns a
64-bit value.

Basically we can use it to implement a hypercall (rather than VMCALL).

For example,
- CPUID 0x48000001.EAX would return the feature presence (e.g. in
EBX), and the result in EDX:EAX (if present) at the same time, or
- CPUID 0x48000001.EAX would return the feature presence only, and
CPUID 0x48000002.EAX (acts like a hypercall) returns up to 4 32-bit
values.

-- 
Jun
Intel Open Source Technology Center

Il 19/09/2014 18:14, Nakajima, Jun ha scritto:
> For example,
> - CPUID 0x48000001.EAX would return the feature presence (e.g. in
> EBX), and the result in EDX:EAX (if present) at the same time, or
> - CPUID 0x48000001.EAX would return the feature presence only, and
> CPUID 0x48000002.EAX (acts like a hypercall) returns up to 4 32-bit
> values.
The latter is much better, because an "unknown" CPUID will return the
value of the highest leaf below 0x80000000, and conflicts can happen easily.

Paolo

On 09/19/2014 09:14 AM, Nakajima, Jun wrote:
> 
> I slept on it, and I think using the CPUID instruction alone would be
> simple and efficient:
> - We have a huge space for CPUID leaves
> - CPUID also works for user-level
> - It can take an additional 32-bit parameter (ECX), and returns 4
> 32-bit values (EAX, EBX, ECX, and EDX).  RDMSR, for example, returns a
> 64-bit value.
> 
> Basically we can use it to implement a hypercall (rather than VMCALL).
> 
> For example,
> - CPUID 0x48000001.EAX would return the feature presence (e.g. in
> EBX), and the result in EDX:EAX (if present) at the same time, or
> - CPUID 0x48000001.EAX would return the feature presence only, and
> CPUID 0x48000002.EAX (acts like a hypercall) returns up to 4 32-bit
> values.
> 
There is a huge disadvantage to the fact that CPUID is a user space
instruction, though.

	-hpa

On Sep 19, 2014 9:40 AM, "H. Peter Anvin" <hpa at zytor.com>
wrote:
>
> On 09/19/2014 09:14 AM, Nakajima, Jun wrote:
> >
> > I slept on it, and I think using the CPUID instruction alone would be
> > simple and efficient:
> > - We have a huge space for CPUID leaves
> > - CPUID also works for user-level
> > - It can take an additional 32-bit parameter (ECX), and returns 4
> > 32-bit values (EAX, EBX, ECX, and EDX).  RDMSR, for example, returns a
> > 64-bit value.
> >
> > Basically we can use it to implement a hypercall (rather than VMCALL).
> >
> > For example,
> > - CPUID 0x48000001.EAX would return the feature presence (e.g. in
> > EBX), and the result in EDX:EAX (if present) at the same time, or
> > - CPUID 0x48000001.EAX would return the feature presence only, and
> > CPUID 0x48000002.EAX (acts like a hypercall) returns up to 4 32-bit
> > values.
> >
>
> There is a huge disadvantage to the fact that CPUID is a user space
> instruction, though.
We can always make cpuid on the leaf in question return all zeros if CPL > 0.
>
>         -hpa
>

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.

       		       	    	    	       - Ted