On 09/19/2014 05:46 PM, H. Peter Anvin wrote:
On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
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
On 09/19/2014 02:42 PM, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
c...@codeaurora.org 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
On 09/22/2014 06:31 AM, Christopher Covington wrote:
On 09/19/2014 05:46 PM, H. Peter Anvin wrote:
On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
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
On 09/22/2014 07:17 AM, H. Peter Anvin wrote:
It could, but how would you enumerate that? A new RDRAND-CPL-0 CPUID
bit pretty much would be required.
Note that there are two things that differ: the CPL 0-ness and the
performance/exhaustibility attributes.
-hpa
--
To unsubscribe
Not really, no.
Sent from my tablet, pardon any formatting problems.
On Sep 22, 2014, at 06:31, Christopher Covington c...@codeaurora.org wrote:
On 09/19/2014 05:46 PM, H. Peter Anvin wrote:
On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
However, it sounds to me that at least for KVM, it
Il 19/09/2014 22:46, Andy Lutomirski ha scritto:
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.
Hi Andy,
On Fri, 2014-09-19 at 11:20 -0700, Andy Lutomirski wrote:
[cc: Alok Kataria at VMware]
On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov g...@kernel.org 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
Il 18/09/2014 23:54, David Hepkin ha scritto:
The chief advantage I see to using a hypercall based mechanism is
that it would work across more architectures. MSR's and CPUID's are
specific to X86. If we ever wanted this same mechanism to be
available on an architecture that doesn't support
On Thu, Sep 18, 2014 at 6:28 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun jun.nakaj...@intel.com
wrote:
On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski
Il 19/09/2014 18:14, Nakajima, Jun ha scritto:
For example,
- CPUID 0x4801.EAX would return the feature presence (e.g. in
EBX), and the result in EDX:EAX (if present) at the same time, or
- CPUID 0x4801.EAX would return the feature presence only, and
CPUID 0x4802.EAX (acts like a
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.
-hpa
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to
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
On Thu, Sep 18, 2014 at 03:00:05PM -0700, Andy Lutomirski wrote:
On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin david...@microsoft.com wrote:
I suggest we come to consensus on a specific CPUID leaf where an OS needs
to look to determine if a hypervisor supports this capability. We could
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)
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. We're talking for uses like kASLR.
Still to early
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
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:
Linux detects what hypervior it
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:
Linux detects what hypervior it
On Sep 19, 2014 9:40 AM, H. Peter Anvin h...@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
On Sep 19, 2014 9:53 AM, Gleb Natapov g...@kernel.org 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. We're talking for uses like
On 09/19/2014 10:21 AM, Andy Lutomirski wrote:
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.
Not sure that is better...
-hpa
--
To unsubscribe from this list:
On Fri, Sep 19, 2014 at 10:36 AM, H. Peter Anvin h...@zytor.com wrote:
On 09/19/2014 10:21 AM, Andy Lutomirski wrote:
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.
Not
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
On Fri, Sep 19, 2014 at 10:21:27AM -0700, Andy Lutomirski wrote:
On Sep 19, 2014 9:53 AM, Gleb Natapov g...@kernel.org 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
On Fri, Sep 19, 2014 at 10:49 AM, Gleb Natapov g...@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 09/19/2014 09:53 AM, Gleb Natapov 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 g...@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.
[cc: Alok Kataria at VMware]
On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov g...@kernel.org 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 g...@kernel.org wrote:
On Fri, Sep 19, 2014 at 10:18:37AM -0700, H. Peter Anvin
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
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
c...@codeaurora.org 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:
-
On Sep 19, 2014, at 9:42 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
c...@codeaurora.org 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
On Fri, Sep 19, 2014 at 1:21 PM, Nadav Amit nadav.a...@gmail.com wrote:
On Sep 19, 2014, at 9:42 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Sep 19, 2014 at 11:30 AM, Christopher Covington
c...@codeaurora.org wrote:
On 09/17/2014 10:50 PM, Andy Lutomirski wrote:
Hi all-
I would
On Fri, Sep 19, 2014 at 11:20:49AM -0700, Andy Lutomirski wrote:
[cc: Alok Kataria at VMware]
On Fri, Sep 19, 2014 at 11:12 AM, Gleb Natapov g...@kernel.org 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
On 09/19/2014 01:46 PM, Andy Lutomirski wrote:
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
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
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
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
On Fri, Sep 19, 2014 at 3:06 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
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,
On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
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.
On Fri, Sep 19, 2014 at 3:57 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 03:06:55PM -0700, Andy Lutomirski wrote:
On Fri, Sep 19, 2014 at 3:05 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 09:40:42AM -0700, H. Peter Anvin wrote:
There is a huge
On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
To force deterministic execution.
I incorrectly thought that the kernel could switch RDRAND on and off.
It turns out that a hypervisor can do this, but not the kernel. Also,
determinism is lost anyway because of TSX, which *also* can't be
On 09/19/2014 04:12 PM, Andy Lutomirski wrote:
To force deterministic execution.
I incorrectly thought that the kernel could switch RDRAND on and off.
It turns out that a hypervisor can do this, but not the kernel. Also,
determinism is lost anyway because of TSX, which *also* can't be
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.
Right, but if the host kernel is dependent on the guest OS for
On Fri, Sep 19, 2014 at 4:35 PM, Theodore Ts'o ty...@mit.edu wrote:
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.
On 09/19/2014 04:35 PM, Theodore Ts'o wrote:
On Fri, Sep 19, 2014 at 04:29:53PM -0700, H. Peter Anvin wrote:
Actually, a much bigger reason is because it lets rogue guest *user
space*, even will a well-behaved guest OS, do something potentially
harmful to the host.
Right, but if the host
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
KVM to implement by using a KVM-specific CPUID
-Original Message-
From: virtualization-boun...@lists.linux-foundation.org
[mailto:virtualization-boun...@lists.linux-foundation.org] On Behalf Of Andy
Lutomirski
Sent: Wednesday, September 17, 2014 7:51 PM
To: Linux Virtualization; kvm list
Cc: Gleb Natapov; Paolo Bonzini;
On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin h...@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.
On Thu, Sep 18, 2014 at 8:38 AM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 18, 2014 at 7:43 AM, H. Peter Anvin h...@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
Il 18/09/2014 17:44, Andy Lutomirski ha scritto:
Slight correction: QEMU/KVM has optional support for Hyper-V feature
enumeration. Ideally the RNG seed mechanism would be enabled by
default, but I don't know whether the QEMU maintainers would be okay
with enabling the Hyper-V cpuid mechanism
-Original Message-
From: Andy Lutomirski [mailto:l...@amacapital.net]
Sent: Thursday, September 18, 2014 8:38 AM
To: H. Peter Anvin
Cc: KY Srinivasan; Linux Virtualization; kvm list; Gleb Natapov; Paolo
Bonzini;
Theodore Ts'o
Subject: Re: Standardizing an MSR or other hypercall
On Thu, Sep 18, 2014 at 9:36 AM, KY Srinivasan k...@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 4000H - 40FFH. The SDM (35.1
ARCHITECTURAL MSRS)
Il 18/09/2014 19:13, Nakajima, Jun ha scritto:
In terms of the address for the MSR, I suggest that you choose one
from the range between 4000H - 40FFH. The SDM (35.1
ARCHITECTURAL MSRS) says All existing and
future processors will not implement any features using any MSR in
this
-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@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;
On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan k...@microsoft.com wrote:
-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@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;
That certainly sound reasonable to me. How do you see discovery of that
working?
Thanks,
Jake Oshins
-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo Bonzini
Sent: Thursday, September 18, 2014 10:18 AM
To: Nakajima, Jun; KY Srinivasan
Cc:
On Thu, Sep 18, 2014 at 10:42 AM, Nakajima, Jun jun.nakaj...@intel.com wrote:
On Thu, Sep 18, 2014 at 10:20 AM, KY Srinivasan k...@microsoft.com wrote:
-Original Message-
From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
Bonzini
Sent: Thursday, September 18,
Quite frankly it might make more sense to define a cross-VM *cpuid* range. The
cpuid leaf can just point to the MSR. The big question is who will be willing
to be the registrar.
On September 18, 2014 11:35:39 AM PDT, Andy Lutomirski l...@amacapital.net
wrote:
On Thu, Sep 18, 2014 at 10:42
However, I think it would be better to have the MSR (and perhaps CPUID)
outside the hypervisor-reserved ranges, so that it becomes architecturally
defined. In some sense it is similar to the HYPERVISOR CPUID feature.
Yes, given that we want this to be hypervisor agnostic.
Actually,
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 documented anywhere, but Linux tries to
detect a hypervisor
On Thu, Sep 18, 2014 at 11:54 AM, Niels Ferguson ni...@microsoft.com wrote:
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
On Thu, Sep 18, 2014 at 11:58 AM, Paolo Bonzini pbonz...@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
On Thu, Sep 18, 2014 at 12:07 PM, Andy Lutomirski l...@amacapital.net wrote:
Might Intel be willing to extend that range to 0x4000 -
0x400f? And would Microsoft be okay with using this mechanism for
discovery?
So, for CPUID, the SDM (Table 3-17. Information Returned by CPUID) says
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
On Thu, Sep 18, 2014 at 2:21 PM, Nakajima, Jun jun.nakaj...@intel.com wrote:
On Thu, Sep 18, 2014 at 12:07 PM, Andy Lutomirski l...@amacapital.net wrote:
Might Intel be willing to extend that range to 0x4000 -
0x400f? And would Microsoft be okay with using this mechanism for
On 09/18/2014 02:46 PM, David Hepkin wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that each
hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f CPUID
range, and an OS has to do a full scan of this CPUID range on boot to find
it? That seems
On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin david...@microsoft.com wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that each
hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f CPUID
range, and an OS has to do a full scan of this CPUID range on
I'm not sure what you mean by this mechanism? Are you suggesting that each
hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f CPUID
range, and an OS has to do a full scan of this CPUID range on boot to find it?
That seems pretty inefficient. An OS will take 1000's of
On 09/18/2014 03:00 PM, Andy Lutomirski wrote:
On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin david...@microsoft.com wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that
each hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f
CPUID range, and an OS
On Thu, Sep 18, 2014 at 2:57 PM, H. Peter Anvin h...@zytor.com wrote:
On 09/18/2014 02:46 PM, David Hepkin wrote:
I'm not sure what you mean by this mechanism? Are you suggesting that
each hypervisor put CrossHVPara\0 somewhere in the 0x4000 - 0x400f
CPUID range, and an OS has to do
The chief advantage I see to using a hypercall based mechanism is that it would
work across more architectures. MSR's and CPUID's are specific to X86. If we
ever wanted this same mechanism to be available on an architecture that doesn't
support MSR's, a hypercall based approach would allow
On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski l...@amacapital.net wrote:
So, as a concrete straw-man:
CPUID leaf 0x4800 would return a maximum leaf number in EAX (e.g.
0x4801) along with a signature value (e.g. CrossHVPara\0) in
EBX, ECX, and EDX.
CPUID 0x4801.EAX would
On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun jun.nakaj...@intel.com wrote:
On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski l...@amacapital.net wrote:
So, as a concrete straw-man:
CPUID leaf 0x4800 would return a maximum leaf number in EAX (e.g.
0x4801) along with a signature value
On Thu, Sep 18, 2014 at 6:03 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, Sep 18, 2014 at 5:49 PM, Nakajima, Jun jun.nakaj...@intel.com wrote:
On Thu, Sep 18, 2014 at 3:07 PM, Andy Lutomirski l...@amacapital.net wrote:
So, as a concrete straw-man:
CPUID leaf 0x4800 would return
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
73 matches
Mail list logo
