[PATCH] random: Add "initialized" variable to proc

[PATCH] random: Add "initialized" variable to proc

[Florian Weimer]

Before this change, you had to check kernel log messages to see if the
non-blocking pool had been properly initialized.  With this change, you
can consult the file /proc/sys/kernel/random/intialized instead.

Signed-off-by: Florian Weimer <fweimer@redhat.com>
---
 drivers/char/random.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/char/random.c b/drivers/char/random.c
index 6b75713..81d83e2 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1592,6 +1592,19 @@ static int proc_do_entropy(ctl_table *table, int write,
 	return proc_dointvec(&fake_table, write, buffer, lenp, ppos);
 }
 
+/*
+ * Return whether the urandom pool has been initialized.
+ */
+static int proc_do_initialized(ctl_table *table, int write,
+			       void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+	ctl_table fake_table;
+	char ch = '0' + nonblocking_pool.initialized;
+	fake_table.data = &ch;
+	fake_table.maxlen = 1;
+	return proc_dostring(&fake_table, write, buffer, lenp, ppos);
+}
+
 static int sysctl_poolsize = INPUT_POOL_WORDS * 32;
 extern struct ctl_table random_table[];
 struct ctl_table random_table[] = {
@@ -1610,6 +1623,12 @@ struct ctl_table random_table[] = {
 		.data		= &input_pool.entropy_count,
 	},
 	{
+		.procname	= "initialized",
+		.maxlen		= 1,
+		.mode		= 0444,
+		.proc_handler	= proc_do_initialized,
+	},
+	{
 		.procname	= "read_wakeup_threshold",
 		.data		= &random_read_wakeup_bits,
 		.maxlen		= sizeof(int),
-- 
1.9.0

Re: [PATCH] random: Add "initialized" variable to proc

[Theodore Ts'o]

On Mon, Apr 28, 2014 at 09:52:11PM +0200, Florian Weimer wrote:
> Before this change, you had to check kernel log messages to see if the
> non-blocking pool had been properly initialized.  With this change, you
> can consult the file /proc/sys/kernel/random/intialized instead.
> 
> Signed-off-by: Florian Weimer <fweimer@redhat.com>

The main reason why I hadn't added a facility like this was because
the main goal was to make knowledge of when the /dev/urandom entropy
pool had been fully initialized could be made clear.  In fact, at
least on my laptop, this happened at 2.5 seconds after boot, which is
after the hard drives had been probed, and before all of the various
laptop devices have been fully probed.

My goal was to see if we could make it be more or less guaranteed that
by the time userspace daemons started coming up, in practice
/dev/urandom would be initialized, so we wouldn't have to change
userspace.  And for the most part, this isn't a problem.

Now there may be systems where the device probe can happen much more
quickly. in which case it does make sense for really paranoid crypto
libraries to check if the urandom pool has been fully initialized.
But in that case, instead of (or perhaps in addition to) providing a
file which a library daemon could poll on, to provide an ioctl
interface which allows userspace to block until /dev/urandom has been
initialized.

						- Ted

Re: [PATCH] random: Add "initialized" variable to proc

[Florian Weimer]

On 04/28/2014 11:41 PM, Theodore Ts'o wrote:
> On Mon, Apr 28, 2014 at 09:52:11PM +0200, Florian Weimer wrote:
>> Before this change, you had to check kernel log messages to see if the
>> non-blocking pool had been properly initialized.  With this change, you
>> can consult the file /proc/sys/kernel/random/intialized instead.
>>
>> Signed-off-by: Florian Weimer <fweimer@redhat.com>
>
> The main reason why I hadn't added a facility like this was because
> the main goal was to make knowledge of when the /dev/urandom entropy
> pool had been fully initialized could be made clear.  In fact, at
> least on my laptop, this happened at 2.5 seconds after boot, which is
> after the hard drives had been probed, and before all of the various
> laptop devices have been fully probed.

I've got a (physical) machine where it happens after ten seconds, or 
much longer if there is no activity.

I've seen cases where on the first boot of virtual machines, the SSH key 
was generated before the printk with the initialization message.  It's 
not a problem if you install the OS first and then generate the keys, 
but for booting from pre-provisioned images, it could be.  (I have no 
evidence that this hurts the quality of the generated key material, this 
is just based on what's reported by the kernel.)

> My goal was to see if we could make it be more or less guaranteed that
> by the time userspace daemons started coming up, in practice
> /dev/urandom would be initialized, so we wouldn't have to change
> userspace.  And for the most part, this isn't a problem.

I'm not sure if I want to bet an increasingly crucial part of the boot 
design on the continuing availability of the current entropy levels 
(which could go down as the result of environmental changes or a 
reassessment of the entropy that actually comes into the system).

> Now there may be systems where the device probe can happen much more
> quickly. in which case it does make sense for really paranoid crypto
> libraries to check if the urandom pool has been fully initialized.
> But in that case, instead of (or perhaps in addition to) providing a
> file which a library daemon could poll on, to provide an ioctl
> interface which allows userspace to block until /dev/urandom has been
> initialized.

Or a new /dev/?random device that blocks until initialized, but behaves 
just like /dev/urandom after that.   The question is how useful it would 
be because of the deadlock scenario.

-- 
Florian Weimer / Red Hat Product Security Team

Re: [PATCH] random: Add "initialized" variable to proc

[Theodore Ts'o]

On Tue, Apr 29, 2014 at 07:51:08PM +0200, Florian Weimer wrote:
> 
> I've got a (physical) machine where it happens after ten seconds, or much
> longer if there is no activity.
> 
> I've seen cases where on the first boot of virtual machines, the SSH key was
> generated before the printk with the initialization message.  It's not a
> problem if you install the OS first and then generate the keys, but for
> booting from pre-provisioned images, it could be.  (I have no evidence that
> this hurts the quality of the generated key material, this is just based on
> what's reported by the kernel.)

Yes, fair enough, just because it works for me for my laptops doesn't
mean that there aren't systems for which it was a problem.  :-)

I will say that for virtual machines, we *really* need virtio-rng.
And I wonder if the right answer is that initially we have some other
process listening on the ssh port, which can generate the ssh host
keys when someone actually first connects to the ssh port (since at
that point, networking will have come up and we'll get some entropy
just from the networking interupts if nothing else), and then exec the
real ssh daemon to handle the incoming connection, as well as execing
a the real ssh daemon to take over listening on the ssh port.

> I'm not sure if I want to bet an increasingly crucial part of the boot
> design on the continuing availability of the current entropy levels (which
> could go down as the result of environmental changes or a reassessment of
> the entropy that actually comes into the system).

It doesn't matter of entropy levels go down; what's important is that
at least at one point, the entropy estimate goes above the threshold
level.  Once that happens, someone can only break the RNG if (a) we
were wrong about the entropy estimate --- and we've made the entropy
estimator extremely conservative for that reason; the academic papers
which have studied /dev/random have not found fault with the
estimator, or (b) someone has broken the underlying crypto algorithm.

> Or a new /dev/?random device that blocks until initialized, but behaves just
> like /dev/urandom after that.   The question is how useful it would be
> because of the deadlock scenario.

It's like any other technology; it depends on how you use it.  If you
don't block the whole boot, but just those services which depend on
the entropy generation (for example, ssh), and there's enough services
up so that the machine has activity so that eventually the initialized
flag is set, it won't be a deadlock.  Maybe it will take five minutes
before the machine is answering ssh queries, and that could be a
support nightmare, sure.  At some level, it's up to use to generate a
system that can generate enough entropy in a reasonable time, which is
why I added the printk in the first place -- to assist in that effort.

So if you're not going to block on the urandom generator being
"initialized" (where the definition, like the entropy estimator, is
somewhat arbitrary), how were you thinking the information from
/proc/sys/kernel/random/intialized would be used?

							- Ted

Re: [PATCH] random: Add "initialized" variable to proc

[Andy Lutomirski]

On 04/29/2014 11:26 AM, Theodore Ts'o wrote:
> On Tue, Apr 29, 2014 at 07:51:08PM +0200, Florian Weimer wrote:
>>
>> I've got a (physical) machine where it happens after ten seconds, or much
>> longer if there is no activity.
>>
>> I've seen cases where on the first boot of virtual machines, the SSH key was
>> generated before the printk with the initialization message.  It's not a
>> problem if you install the OS first and then generate the keys, but for
>> booting from pre-provisioned images, it could be.  (I have no evidence that
>> this hurts the quality of the generated key material, this is just based on
>> what's reported by the kernel.)
> 
> Yes, fair enough, just because it works for me for my laptops doesn't
> mean that there aren't systems for which it was a problem.  :-)
> 
> I will say that for virtual machines, we *really* need virtio-rng.

I only sort of agree.  I think that for VMs, we really need a good way
to provide an initial seed and ongoing entropy, and virtio-rng isn't it.

IMO virtio-rng is, alas, terminally fscked up.  It has four issues, all
show-stopping.  Fixing them may be impossible without changing the
interface.

1. It simply doesn't work on my system.  In particular, it never returns
entropy.  It just blocks forever.

2. The hwrng code sucks and the guest will never boot if there's a
non-working virtio-rng device around.  See #1.  I *may* get around to
writing a patch for this before the next merge window.

3. There should be a way to provide some entropy-free cryptographically
secure data, too.  Regardless of the speed of the hosts's /dev/random,
the guest should start with at least 256 bits of cryptographically
secure seed material IMO.

4. virtio-pci and its asynchronous interface are too complicated to
achieve #3, even if a future virtio-rng enhancement could provide
urandom-like data.  This thing is paravirt hardware; it should be able
to provide a seed *really* early.

--Andy

Re: [PATCH] random: Add "initialized" variable to proc

[Theodore Ts'o]

On Wed, Apr 30, 2014 at 01:52:35PM -0700, Andy Lutomirski wrote:
> 
> 1. It simply doesn't work on my system.  In particular, it never returns
> entropy.  It just blocks forever.

Why?  Is this a bug in qemu?  The host OS?  The guest OS?  It is qemu
trying to use /dev/random instead of /dev/urandom?  Any thing else?

> 3. There should be a way to provide some entropy-free cryptographically
> secure data, too.  Regardless of the speed of the hosts's /dev/random,
> the guest should start with at least 256 bits of cryptographically
> secure seed material IMO.

Well, the simplest way to do this is to pass it in via the command
line, and then have the the kernel make sure it gets obscured so it's
not exposed via /proc/cmdline.

Otherwise we would have to define an extension where we pass 32 bytes
or so after the boot command line.  But the downside of doing that is
we would have to modify every single architecture to define where
those 32 bytes could be found.

Aside from passing it on the command line as being a bit grotty, the
other big problem this is that some architectures only have 256 bytes
of command line, and if we use a base 64 encoding, 256 bits will take
43 characters.  Not a problem on x86, and it seems rather unlikely
that people would want to virtualize a m68k or avr32 CPU.  It just
feels really unclean.

I've cc'ed Peter Anvin for his opinion about extending Linux boot
parameter protocol.  I agree it would be a lot simpler and easier to
enable things like Kernel ASLR with real randomness on guest OS's if
we didn't have to erect the whole virtio-pci infrastructure during
early boot.  :-)

						 -Ted

Re: [PATCH] random: Add "initialized" variable to proc

[H. Peter Anvin]

Qemu is using /dev/random because there is no point in emptily feeding one prng from another.


Giving the guest a seed would be highly useful, though.  There are a number of ways to do that; changing the boot protocol is probably only useful if Qemu itself bouts the kernel as opposed to an in-VM bootloader.

That leaves several options other than virtio: I/O port, magic number in memory, CPUID, MSR, or even emulating RDRAND/RDSEED in the VMM.

On April 30, 2014 7:06:27 PM PDT, Theodore Ts'o <tytso@mit.edu> wrote:
>On Wed, Apr 30, 2014 at 01:52:35PM -0700, Andy Lutomirski wrote:
>> 
>> 1. It simply doesn't work on my system.  In particular, it never
>returns
>> entropy.  It just blocks forever.
>
>Why?  Is this a bug in qemu?  The host OS?  The guest OS?  It is qemu
>trying to use /dev/random instead of /dev/urandom?  Any thing else?
>
>> 3. There should be a way to provide some entropy-free
>cryptographically
>> secure data, too.  Regardless of the speed of the hosts's
>/dev/random,
>> the guest should start with at least 256 bits of cryptographically
>> secure seed material IMO.
>
>Well, the simplest way to do this is to pass it in via the command
>line, and then have the the kernel make sure it gets obscured so it's
>not exposed via /proc/cmdline.
>
>Otherwise we would have to define an extension where we pass 32 bytes
>or so after the boot command line.  But the downside of doing that is
>we would have to modify every single architecture to define where
>those 32 bytes could be found.
>
>Aside from passing it on the command line as being a bit grotty, the
>other big problem this is that some architectures only have 256 bytes
>of command line, and if we use a base 64 encoding, 256 bits will take
>43 characters.  Not a problem on x86, and it seems rather unlikely
>that people would want to virtualize a m68k or avr32 CPU.  It just
>feels really unclean.
>
>I've cc'ed Peter Anvin for his opinion about extending Linux boot
>parameter protocol.  I agree it would be a lot simpler and easier to
>enable things like Kernel ASLR with real randomness on guest OS's if
>we didn't have to erect the whole virtio-pci infrastructure during
>early boot.  :-)
>
>						 -Ted

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.

Re: [PATCH] random: Add "initialized" variable to proc

[H. Peter Anvin]

To do something cross-arch putting it in memory and having something point to it is probably easiest, but again, with an in-VM boot loader the command line rather sucks.  This then becomes a matter for device tree/ACPI with all that entails.

In that sense it would be better to do something arch-specififc, because what is easy to do early is rather inherently arch-specific.

Sent from my tablet, pardon any formatting problems.

> On Apr 30, 2014, at 19:06, "Theodore Ts'o" <tytso@mit.edu> wrote:
> 
>> On Wed, Apr 30, 2014 at 01:52:35PM -0700, Andy Lutomirski wrote:
>> 
>> 1. It simply doesn't work on my system.  In particular, it never returns
>> entropy.  It just blocks forever.
> 
> Why?  Is this a bug in qemu?  The host OS?  The guest OS?  It is qemu
> trying to use /dev/random instead of /dev/urandom?  Any thing else?
> 
>> 3. There should be a way to provide some entropy-free cryptographically
>> secure data, too.  Regardless of the speed of the hosts's /dev/random,
>> the guest should start with at least 256 bits of cryptographically
>> secure seed material IMO.
> 
> Well, the simplest way to do this is to pass it in via the command
> line, and then have the the kernel make sure it gets obscured so it's
> not exposed via /proc/cmdline.
> 
> Otherwise we would have to define an extension where we pass 32 bytes
> or so after the boot command line.  But the downside of doing that is
> we would have to modify every single architecture to define where
> those 32 bytes could be found.
> 
> Aside from passing it on the command line as being a bit grotty, the
> other big problem this is that some architectures only have 256 bytes
> of command line, and if we use a base 64 encoding, 256 bits will take
> 43 characters.  Not a problem on x86, and it seems rather unlikely
> that people would want to virtualize a m68k or avr32 CPU.  It just
> feels really unclean.
> 
> I've cc'ed Peter Anvin for his opinion about extending Linux boot
> parameter protocol.  I agree it would be a lot simpler and easier to
> enable things like Kernel ASLR with real randomness on guest OS's if
> we didn't have to erect the whole virtio-pci infrastructure during
> early boot.  :-)
> 
>                         -Ted

Re: [PATCH] random: Add "initialized" variable to proc

[Jason Cooper]

On Wed, Apr 30, 2014 at 10:37:00PM -0700, H. Peter Anvin wrote:
> 
> > On Apr 30, 2014, at 19:06, "Theodore Ts'o" <tytso@mit.edu> wrote:
> > 
> >> On Wed, Apr 30, 2014 at 01:52:35PM -0700, Andy Lutomirski wrote:
> >> 
> >> 1. It simply doesn't work on my system.  In particular, it never returns
> >> entropy.  It just blocks forever.
> > 
> > Why?  Is this a bug in qemu?  The host OS?  The guest OS?  It is qemu
> > trying to use /dev/random instead of /dev/urandom?  Any thing else?
> > 
> >> 3. There should be a way to provide some entropy-free cryptographically
> >> secure data, too.  Regardless of the speed of the hosts's /dev/random,
> >> the guest should start with at least 256 bits of cryptographically
> >> secure seed material IMO.
> > 
> > Well, the simplest way to do this is to pass it in via the command
> > line, and then have the the kernel make sure it gets obscured so it's
> > not exposed via /proc/cmdline.
> > 
> > Otherwise we would have to define an extension where we pass 32 bytes
> > or so after the boot command line.  But the downside of doing that is
> > we would have to modify every single architecture to define where
> > those 32 bytes could be found.
> > 
> > Aside from passing it on the command line as being a bit grotty, the
> > other big problem this is that some architectures only have 256 bytes
> > of command line, and if we use a base 64 encoding, 256 bits will take
> > 43 characters.  Not a problem on x86, and it seems rather unlikely
> > that people would want to virtualize a m68k or avr32 CPU.  It just
> > feels really unclean.
> > 
> > I've cc'ed Peter Anvin for his opinion about extending Linux boot
> > parameter protocol.  I agree it would be a lot simpler and easier to
> > enable things like Kernel ASLR with real randomness on guest OS's if
> > we didn't have to erect the whole virtio-pci infrastructure during
> > early boot.  :-)
> 
> To do something cross-arch putting it in memory and having something
> point to it is probably easiest, but again, with an in-VM boot loader
> the command line rather sucks.  This then becomes a matter for device
> tree/ACPI with all that entails.

I drafted an idea for how to improve early-boot randomness on ARM [1] a
ways back.  Requoting:

"""
On Wednesday 12 February 2014 13:45:21 Jason Cooper wrote:
> On Wed, Feb 12, 2014 at 07:17:41PM +0100, Arnd Bergmann wrote:
> > On Wednesday 12 February 2014 12:45:54 Jason Cooper wrote:
> > > I brought this up at last weeks devicetree irc meeting.  My goal
> > > is to provide early randomness for kaslr on ARM.  Currently, my
> > > idea is modify the init script to save an additional random seed
> > > from /dev/urandom to /boot/random-seed.
> > > 
> > > The bootloader would then load this file into ram, and pass the
> > > address/size to the kernel either via dt, or commandline.  kaslr
> > > (run in the decompressor) would consume some of this randomness,
> > > and then random.c would consume the rest in a non-crediting
> > > initialization.
> > 
> > I like the idea, but wouldn't it be easier to pass actual random
> > data using DT, rather than the address/size?
> 
> I thought about that at first, but that requires either that the
> bootloader be upgraded to insert the data, or that userspace is
> modifying the dtb at least twice per boot.
> 
> I chose address/size to facilitate modifying existing/fielded devices.
> The user could modify the dtb once, and modify the bootloader
> environment to load X amount to Y address.  As a fallback, it could be
> expressed on the commandline for non-DT bootloaders.

Ah, so you are interested in boot loaders that can be scripted to do
what you had in mind but cannot be scripted to add or modify a DT
property. I hadn't considered that, but you are probably right that
this is at least 90% of the systems you'd find in the wild today.
[...]
	Arnd
"""

I'm not sure how it would play out on other arch's, or with ACPI.  But
if there's interest, I could try to spend some cycles in the next few
weeks to create an RFC.

thx,

Jason.

[1] http://marc.info/?l=linux-kernel&m=139223237824952&w=2

Re: [PATCH] random: Add "initialized" variable to proc

[tytso]

On Wed, Apr 30, 2014 at 09:05:00PM -0700, H. Peter Anvin wrote:
> 
> Giving the guest a seed would be highly useful, though.  There are a
> number of ways to do that; changing the boot protocol is probably
> only useful if Qemu itself bouts the kernel as opposed to an in-VM
> bootloader.

So how about simply passing a memory address and an optional offset on
the boot command line?  That way the hypervisor can drop the seed in
some convenient real memory location, and the kernel can just copy it
someplace safe, or in the case of kernel ASLR, the relocator can use
it to seed its CRNG, and then after it relocates the kernel, it can
crank the CRNG to pass a seed to the kernel's urandom driver.

That way, we don't have to do something which is ACPI or DT dependent.
Maybe there will be embedded architectures where using DT might be
more convenient, but this would probably be simplest for KVM/qumu-based
VM's, I would think.

     	     	   	      		- Ted

Re: [PATCH] random: Add "initialized" variable to proc

[Andy Lutomirski]

On Thu, May 1, 2014 at 8:05 AM,  <tytso@mit.edu> wrote:
> On Wed, Apr 30, 2014 at 09:05:00PM -0700, H. Peter Anvin wrote:
>>
>> Giving the guest a seed would be highly useful, though.  There are a
>> number of ways to do that; changing the boot protocol is probably
>> only useful if Qemu itself bouts the kernel as opposed to an in-VM
>> bootloader.
>
> So how about simply passing a memory address and an optional offset on
> the boot command line?  That way the hypervisor can drop the seed in
> some convenient real memory location, and the kernel can just copy it
> someplace safe, or in the case of kernel ASLR, the relocator can use
> it to seed its CRNG, and then after it relocates the kernel, it can
> crank the CRNG to pass a seed to the kernel's urandom driver.
>
> That way, we don't have to do something which is ACPI or DT dependent.
> Maybe there will be embedded architectures where using DT might be
> more convenient, but this would probably be simplest for KVM/qumu-based
> VM's, I would think.

One problem with passing a seed in memory like this is that it
provides no benefit if the guest reboots without restarting the
hypervisor.  Using an MSR or something avoids that issue.

Passing an address in I/O space that can be read to synchronously
obtain a seed would work, but it could still be messy to get the
address to propagate through the booatloader and the reboot process.

--Andy

Re: [PATCH] random: Add "initialized" variable to proc

[Andy Lutomirski]

On Thu, May 1, 2014 at 8:35 AM, Andy Lutomirski <luto@amacapital.net> wrote:
> On Thu, May 1, 2014 at 8:05 AM,  <tytso@mit.edu> wrote:
>> On Wed, Apr 30, 2014 at 09:05:00PM -0700, H. Peter Anvin wrote:
>>>
>>> Giving the guest a seed would be highly useful, though.  There are a
>>> number of ways to do that; changing the boot protocol is probably
>>> only useful if Qemu itself bouts the kernel as opposed to an in-VM
>>> bootloader.
>>
>> So how about simply passing a memory address and an optional offset on
>> the boot command line?  That way the hypervisor can drop the seed in
>> some convenient real memory location, and the kernel can just copy it
>> someplace safe, or in the case of kernel ASLR, the relocator can use
>> it to seed its CRNG, and then after it relocates the kernel, it can
>> crank the CRNG to pass a seed to the kernel's urandom driver.
>>
>> That way, we don't have to do something which is ACPI or DT dependent.
>> Maybe there will be embedded architectures where using DT might be
>> more convenient, but this would probably be simplest for KVM/qumu-based
>> VM's, I would think.
>
> One problem with passing a seed in memory like this is that it
> provides no benefit if the guest reboots without restarting the
> hypervisor.  Using an MSR or something avoids that issue.
>
> Passing an address in I/O space that can be read to synchronously
> obtain a seed would work, but it could still be messy to get the
> address to propagate through the booatloader and the reboot process.
>

A CPUID leaf or an MSR advertised by a CPUID leaf has another
advantage: it's easy to use in the ASLR code -- I don't think there's
a real IDT, so there's nothing like rdmsr_safe available.  It also
avoids doing anything complicated with the boot process to allow the
same seed to be used for ASLR and random.c; it can just be invoked
twice on boot.

Here are two easyish ways to do it:

a. Add a new CPUID leaf KVM_CPUID_URANDOM = 0x40000002.  The existence
of the leaf is signaled by KVM_CPUID_SIGNATURE.eax >= 0x40000002.
Reading the leaf either gives all zeros to indicate that it's
unsupported or disabled or it gives 256 bits of urandom-style data in
rax,rbx,rcx,edx.  32-bit callers will have trouble extracting more
than 128 of those 256 bits, but that should be fine.

b. Add a new MSR_KVM_URANDOM and indicate support using
KVM_FEATURE_URANDOM.  The is cleaner, since it matches existing
practice, but it's awkward to return more than 64 bits at a time from
rdmsr.  128 bits is straightforward by cheating and using the high
bits in rax and rdx, but that's kind of gross.  Clobbering any more
registers is awful, and passing a pointer into wrmsr seems
overcomplicated.

There's also the hypercall interface, but it looks like hyperv support
can interfere with it, and I'm not sure whether the guest needs to
cooperate with whatever the magical vmcall patching code is doing.

What's the right forum for this?  This thread is probably not it.

--Andy

random: Providing a seed value to VM guests

[H. Peter Anvin]

On 05/01/2014 11:53 AM, Andy Lutomirski wrote:
> 
> A CPUID leaf or an MSR advertised by a CPUID leaf has another
> advantage: it's easy to use in the ASLR code -- I don't think there's
> a real IDT, so there's nothing like rdmsr_safe available.  It also
> avoids doing anything complicated with the boot process to allow the
> same seed to be used for ASLR and random.c; it can just be invoked
> twice on boot.
> 

At that point we are talking an x86-specific interface, and so we might
as well simply emulate RDRAND (urandom) and RDSEED (random) if the CPU
doesn't support them.  I believe KVM already has a way to report CPUID
features that are "emulated but supported anyway", i.e. they work but
are slow.

> What's the right forum for this?  This thread is probably not it.

Change the subject line?

	-hpa