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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> -----Original Message-----
> From: virtualization-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx
> [mailto:virtualization-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Andy
> Lutomirski
> Sent: Wednesday, September 17, 2014 7:51 PM
> To: Linux Virtualization; kvm list
> Cc: Gleb Natapov; Paolo Bonzini; Theodore Ts'o; H. Peter Anvin
> Subject: Standardizing an MSR or other hypercall to get an RNG seed?
> 
> 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.
> 
>  - It should be synchronous.  We don't want to delay boot while waiting for a
> slow host RNG.  (On Linux, at least, we have a separate interface for that:
> virtio-rng.  I think that Windows has some support for virtio-rng as well.)
> 
>  - Random numbers obtained through this interface should be best-effort.
> We want the best quality randomness that the host can provide
> immediately.
> 
> It seems to me that the best interface for the actual request for a random
> number is rdmsr.  This is supported on all hypervisors and all virtualization
> technologies.  It can return a 64 bit random number, and it is easy to rdmsr
> the same register more than once to get a larger random number.
> 
> The main questions are what MSR index to use and how to detect the
> presence of the MSR.  I've played with two approaches:
> 
> 1. Use CPUID to detect the presence of this feature.  This is very easy for
> KVM to implement by using a KVM-specific CPUID feature.  The problem is
> that this will necessarily be KVM-specific, as the guest must first probe for
> KVM and then probe for the KVM feature.  I doubt that Hyper-V, for
> example, wants to claim to be KVM.  If we could standardize a non-
> hypervisor-specific CPUID feature, then this problem would go away.

We would prefer a CPUID feature bit to detect this feature.
 
> 
> 2. Detect the existence of the MSR by trying to read it and handling the
> #GP(0) that will occur if the MSR is not present.  Linux, at least, is okay with
> doing this, and I have code to enable an IDT and an rdmsr fixup early enough
> in boot to use it for ASLR.  I don't know whether other operating systems can
> do this, though.
> 
> The major questions, then, are what enumeration mechanism should be
> used and what MSR index should be used.
> 
> For the MSR index, we could use an MSR from the Intel range if Intel were to
> give explicit approval, thus guaranteeing that nothing would conflict.  Or we
> could try to agree on an MSR index in the 0x40000000-0x4fffffff range that is
> unlikely to conflict with anything.
> 
> For enumeration, we could just probe the MSR if all relevant guests are okay
> with this or we could standardize on a CPUID-based mechanism.
> If we do the latter, I don't know what that mechanism would be.
> 
> NB: This thread will be cc'd to Microsoft and possibly Hyper-V people shortly.
> I very much appreciate Jun Nakajima's help with this!
> 
> Thanks,
> Andy


Regards,

K. Y
> 
> --
> Andy Lutomirski
> AMA Capital Management, LLC
> _______________________________________________
> Virtualization mailing list
> Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
> https://lists.linuxfoundation.org/mailman/listinfo/virtualization
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux