similar to: [RFC] Hypervisor RNG and enumeration

On 29/10/14 05:19, Andy Lutomirski wrote: > Here's a draft CommonHV spec. It's also on github: > > https://github.com/amluto/CommonHV > > So far, this provides a two-way RNG interface, a way to detect it, and > a way to detect other hypervisor leaves. The latter is because, after > both the enormous public thread and some private discussions, it seems > that

On 29/10/14 05:19, Andy Lutomirski wrote: > Here's a draft CommonHV spec. It's also on github: > > https://github.com/amluto/CommonHV > > So far, this provides a two-way RNG interface, a way to detect it, and > a way to detect other hypervisor leaves. The latter is because, after > both the enormous public thread and some private discussions, it seems > that

On Thu, Oct 30, 2014 at 5:21 AM, David Vrabel <david.vrabel at citrix.com> wrote: > On 29/10/14 05:19, Andy Lutomirski wrote: >> CPUID leaf 4F000002H: miscellaneous features >> -------------------------------------------- >> > [...] >> ### CommonHV RNG >> >> If CPUID.4F000002H.EAX is nonzero, then it contains an MSR index used to >> communicate

On Thu, Oct 30, 2014 at 5:21 AM, David Vrabel <david.vrabel at citrix.com> wrote: > On 29/10/14 05:19, Andy Lutomirski wrote: >> CPUID leaf 4F000002H: miscellaneous features >> -------------------------------------------- >> > [...] >> ### CommonHV RNG >> >> If CPUID.4F000002H.EAX is nonzero, then it contains an MSR index used to >> communicate

On 29/10/14 05:19, Andy Lutomirski wrote: > CPUID leaf 4F000002H: miscellaneous features > -------------------------------------------- > [...] > ### CommonHV RNG > > If CPUID.4F000002H.EAX is nonzero, then it contains an MSR index used to > communicate with a hypervisor random number generator. This MSR is > referred to as MSR_COMMONHV_RNG. > >

Defining a standard way of transferring random numbers between the host and the guest is an excellent idea. As the person who writes the RNG code in Windows, I have a few comments: DETECTION: It should be possible to detect this feature through CPUID or similar mechanism. That allows the code that uses this feature to be written without needing the ability to catch CPU exceptions. I could be

Defining a standard way of transferring random numbers between the host and the guest is an excellent idea. As the person who writes the RNG code in Windows, I have a few comments: DETECTION: It should be possible to detect this feature through CPUID or similar mechanism. That allows the code that uses this feature to be written without needing the ability to catch CPU exceptions. I could be

On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote: > On 09/19/2014 10:15 AM, Gleb Natapov wrote: > > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: > >> On 09/19/2014 09:53 AM, Gleb Natapov wrote: > >>> On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote: > >>>> On 09/19/2014 09:37 AM, Gleb Natapov wrote: >

On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote: > On 09/19/2014 10:15 AM, Gleb Natapov wrote: > > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: > >> On 09/19/2014 09:53 AM, Gleb Natapov wrote: > >>> On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote: > >>>> On 09/19/2014 09:37 AM, Gleb Natapov wrote: >

On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov <gleb at kernel.org> wrote: > > On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote: > >> On 09/19/2014 10:15 AM, Gleb Natapov wrote: > >> > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: > >> >> On

On Fri, Sep 19, 2014 at 11:02:38AM -0700, Andy Lutomirski wrote: > On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov <gleb at kernel.org> wrote: > > On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin wrote: > >> On 09/19/2014 10:15 AM, Gleb Natapov wrote: > >> > On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: > >> >> On

On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: > On 09/19/2014 09:53 AM, Gleb Natapov wrote: > > On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote: > >> On 09/19/2014 09:37 AM, Gleb Natapov wrote: > >>> > >>> Linux detects what hypervior it runs on very early > >> > >> Not anywhere close to early enough.

On Fri, Sep 19, 2014 at 10:08:20AM -0700, H. Peter Anvin wrote: > On 09/19/2014 09:53 AM, Gleb Natapov wrote: > > On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote: > >> On 09/19/2014 09:37 AM, Gleb Natapov wrote: > >>> > >>> Linux detects what hypervior it runs on very early > >> > >> Not anywhere close to early enough.

I have finally gotten off the pot and finished writing up my new CPUID/MSR driver, which contains support for registers that need arbitrary GPRs touched. For i386 vs x86-64 compatibility, both use an x86-64 register image (16 64-bit register fields); this allows 32-bit userspace to access the full 64-bit image if the kernel is 64 bits. Anyway, this presumably requires new paravirtualization

I have finally gotten off the pot and finished writing up my new CPUID/MSR driver, which contains support for registers that need arbitrary GPRs touched. For i386 vs x86-64 compatibility, both use an x86-64 register image (16 64-bit register fields); this allows 32-bit userspace to access the full 64-bit image if the kernel is 64 bits. Anyway, this presumably requires new paravirtualization

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

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

On 2/11/20 5:52 AM, Joerg Roedel wrote: > Implement a handler for #VC exceptions caused by RDMSR/WRMSR > instructions. As a general comment on all of these event handlers: Why do we bother having the hypercalls in the interrupt handler as opposed to just calling them directly. What you have is: wrmsr() -> #VC exception hcall() But we could make our rd/wrmsr() wrappers just do:

On 2/11/20 5:52 AM, Joerg Roedel wrote: > Implement a handler for #VC exceptions caused by RDMSR/WRMSR > instructions. As a general comment on all of these event handlers: Why do we bother having the hypercalls in the interrupt handler as opposed to just calling them directly. What you have is: wrmsr() -> #VC exception hcall() But we could make our rd/wrmsr() wrappers just do:

On Fri, Sep 19, 2014 at 09:40:07AM -0700, H. Peter Anvin wrote: > On 09/19/2014 09:37 AM, Gleb Natapov wrote: > > > > Linux detects what hypervior it runs on very early > > Not anywhere close to early enough. We're talking for uses like kASLR. > Still to early to do: h = cpuid(HYPERVIOR_SIGNATURE) if (h == KVMKVMKVM) { if (cpuid(kvm_features) &