similar to: GET_RNG_SEED hypercall ABI? (Re: [PATCH v5 0/5] random,x86,kvm: Rework arch RNG seeds and get some from kvm)

On Aug 28, 2014 7:17 AM, "Gleb Natapov" <gleb at kernel.org> wrote: > > On Tue, Aug 26, 2014 at 04:58:34PM -0700, Andy Lutomirski wrote: > > hpa pointed out that the ABI that I chose (an MSR from the KVM range > > and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice > > to allocate an MSR that everyone involved can agree on and, rather >

On Aug 28, 2014 7:17 AM, "Gleb Natapov" <gleb at kernel.org> wrote: > > On Tue, Aug 26, 2014 at 04:58:34PM -0700, Andy Lutomirski wrote: > > hpa pointed out that the ABI that I chose (an MSR from the KVM range > > and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice > > to allocate an MSR that everyone involved can agree on and, rather >

On Thu, Aug 28, 2014 at 12:46 PM, Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 28/08/2014 18:22, Andy Lutomirski ha scritto: >> Is there a non-cpuid interface between QEMU and KVM for this? > > No. Hmm. Then, assuming that someone manages to allocate a cross-hypervisor MSR number for this, what am I supposed to do in the KVM code? Just make it available

On Thu, Aug 28, 2014 at 12:46 PM, Paolo Bonzini <pbonzini at redhat.com> wrote: > Il 28/08/2014 18:22, Andy Lutomirski ha scritto: >> Is there a non-cpuid interface between QEMU and KVM for this? > > No. Hmm. Then, assuming that someone manages to allocate a cross-hypervisor MSR number for this, what am I supposed to do in the KVM code? Just make it available

Il 27/08/2014 01:58, Andy Lutomirski ha scritto: > hpa pointed out that the ABI that I chose (an MSR from the KVM range > and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice > to allocate an MSR that everyone involved can agree on and, rather > than relying on a cpuid bit, just have the guest probe for the MSR. > > This leads to a few questions: > > 1.

On Tue, Aug 26, 2014 at 04:58:34PM -0700, Andy Lutomirski wrote: > hpa pointed out that the ABI that I chose (an MSR from the KVM range > and a KVM cpuid bit) is unnecessarily KVM-specific. It would be nice > to allocate an MSR that everyone involved can agree on and, rather > than relying on a cpuid bit, just have the guest probe for the MSR. > CPUID part allows feature to be

Il 28/08/2014 18:22, Andy Lutomirski ha scritto: > Is there a non-cpuid interface between QEMU and KVM for this? No. > AFAICT, even turning off cpuid bits for things like async pf doesn't > actually disable the MSRs (which is arguably an attack surface issue). No, it doesn't. You cannot disable instructions even if you hide CPUID bits, so KVM just extends this to MSRs (both

> -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo > Bonzini > Sent: Thursday, September 18, 2014 10:18 AM > To: Nakajima, Jun; KY Srinivasan > Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels > Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux > Virtualization

> -----Original Message----- > From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo > Bonzini > Sent: Thursday, September 18, 2014 10:18 AM > To: Nakajima, Jun; KY Srinivasan > Cc: Mathew John; Theodore Ts'o; John Starks; kvm list; Gleb Natapov; Niels > Ferguson; Andy Lutomirski; David Hepkin; H. Peter Anvin; Jake Oshins; Linux > Virtualization

On Thu, Sep 18, 2014 at 9:36 AM, KY Srinivasan <kys at microsoft.com> wrote: > > I am copying other Hyper-V engineers to this discussion. > Thanks, K.Y. In terms of the address for the MSR, I suggest that you choose one from the range between 40000000H - 400000FFH. The SDM (35.1 ARCHITECTURAL MSRS) says "All existing and future processors will not implement any features using

On Thu, Sep 18, 2014 at 9:36 AM, KY Srinivasan <kys at microsoft.com> wrote: > > I am copying other Hyper-V engineers to this discussion. > Thanks, K.Y. In terms of the address for the MSR, I suggest that you choose one from the range between 40000000H - 400000FFH. The SDM (35.1 ARCHITECTURAL MSRS) says "All existing and future processors will not implement any features using

On Thu, Sep 18, 2014 at 10:42 AM, Nakajima, Jun <jun.nakajima at intel.com> wrote: > On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan <kys at microsoft.com> wrote: >> >> >>> -----Original Message----- >>> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo >>> Bonzini >>> Sent: Thursday, September 18, 2014 10:18

On Thu, Sep 18, 2014 at 10:42 AM, Nakajima, Jun <jun.nakajima at intel.com> wrote: > On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan <kys at microsoft.com> wrote: >> >> >>> -----Original Message----- >>> From: Paolo Bonzini [mailto:paolo.bonzini at gmail.com] On Behalf Of Paolo >>> Bonzini >>> Sent: Thursday, September 18, 2014 10:18

On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin <hpa at zytor.com> wrote: > On 09/18/2014 07:40 AM, KY Srinivasan wrote: >>> >>> 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

On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin <hpa at zytor.com> wrote: > On 09/18/2014 07:40 AM, KY Srinivasan wrote: >>> >>> 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

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

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

On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini <pbonzini at redhat.com> wrote: > >> > Actually, that MSR address range has been reserved for that purpose, along >> > with: >> > - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal) >> > - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID) >> >> I don't know whether this is

On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini <pbonzini at redhat.com> wrote: > >> > Actually, that MSR address range has been reserved for that purpose, along >> > with: >> > - CPUID.EAX=1 -> ECX bit 31 (always returns 0 on bare metal) >> > - CPUID.EAX=4000_00xxH leaves (i.e. HYPERVISOR CPUID) >> >> I don't know whether this is

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