[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

[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

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: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 11:59 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> 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.

Do existing kernels and userspace respect this?  If the normal bit for
RDRAND is unset, then we might be okay, but, if not, then I think this
may kill guest performance.

Is RDSEED really reasonable here?  Won't it slow down by several
orders of magnitude?

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

:)

>
>         -hpa
>
>



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: random: Providing a seed value to VM guests

[tytso]

On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
> 
> Is RDSEED really reasonable here?  Won't it slow down by several
> orders of magnitude?

That is I think the biggest problem; RDRAND and RDSEED are fast if
they are native, but they will involve a VM exit if they need to be
emulated.  So when an OS might want to use RDRAND and RDSEED might be
quite different if we know they are being emulated.

Using the RDRAND and RDSEED "api" certainly makes sense, at least for
x86, but I suspect we might want to use a different way of signalling
that a VM guest can use RDRAND and RDSEED if they are running on a CPU
which doesn't provide that kind of access.  Maybe a CPUID extended
function parameter, if one could be allocated for use by a Linux
hypervisor?

						- Ted

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

As I said... I think KVM has already added an emulated instructions enumeration API.

On May 1, 2014 12:26:18 PM PDT, tytso@mit.edu wrote:
>On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
>> 
>> Is RDSEED really reasonable here?  Won't it slow down by several
>> orders of magnitude?
>
>That is I think the biggest problem; RDRAND and RDSEED are fast if
>they are native, but they will involve a VM exit if they need to be
>emulated.  So when an OS might want to use RDRAND and RDSEED might be
>quite different if we know they are being emulated.
>
>Using the RDRAND and RDSEED "api" certainly makes sense, at least for
>x86, but I suspect we might want to use a different way of signalling
>that a VM guest can use RDRAND and RDSEED if they are running on a CPU
>which doesn't provide that kind of access.  Maybe a CPUID extended
>function parameter, if one could be allocated for use by a Linux
>hypervisor?
>
>						- Ted

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

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On May 1, 2014 12:26 PM, <tytso@mit.edu> wrote:
>
> On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
> >
> > Is RDSEED really reasonable here?  Won't it slow down by several
> > orders of magnitude?
>
> That is I think the biggest problem; RDRAND and RDSEED are fast if
> they are native, but they will involve a VM exit if they need to be
> emulated.  So when an OS might want to use RDRAND and RDSEED might be
> quite different if we know they are being emulated.
>
> Using the RDRAND and RDSEED "api" certainly makes sense, at least for
> x86, but I suspect we might want to use a different way of signalling
> that a VM guest can use RDRAND and RDSEED if they are running on a CPU
> which doesn't provide that kind of access.  Maybe a CPUID extended
> function parameter, if one could be allocated for use by a Linux
> hypervisor?
>

I'm still not convinced.  This will affect userspace as well as the
guest kernel, and I don't see why guest user code should be able to
access this API.  RDRAND for CPL0 only would work, but that seems odd.

And I think that RDSEED emulation is asking for trouble.  RDSEED is
synchronous, but /dev/random is asynchronous.  And making bootup wait
for even a single byte from /dev/random seems bad.  In any event,
virtio-rng should be a better interface for this.

>                                                 - Ted
>

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

RDSEED is not synchronous.  It is, however, nonblocking.

On May 1, 2014 1:16:40 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On May 1, 2014 12:26 PM, <tytso@mit.edu> wrote:
>>
>> On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
>> >
>> > Is RDSEED really reasonable here?  Won't it slow down by several
>> > orders of magnitude?
>>
>> That is I think the biggest problem; RDRAND and RDSEED are fast if
>> they are native, but they will involve a VM exit if they need to be
>> emulated.  So when an OS might want to use RDRAND and RDSEED might be
>> quite different if we know they are being emulated.
>>
>> Using the RDRAND and RDSEED "api" certainly makes sense, at least for
>> x86, but I suspect we might want to use a different way of signalling
>> that a VM guest can use RDRAND and RDSEED if they are running on a
>CPU
>> which doesn't provide that kind of access.  Maybe a CPUID extended
>> function parameter, if one could be allocated for use by a Linux
>> hypervisor?
>>
>
>I'm still not convinced.  This will affect userspace as well as the
>guest kernel, and I don't see why guest user code should be able to
>access this API.  RDRAND for CPL0 only would work, but that seems odd.
>
>And I think that RDSEED emulation is asking for trouble.  RDSEED is
>synchronous, but /dev/random is asynchronous.  And making bootup wait
>for even a single byte from /dev/random seems bad.  In any event,
>virtio-rng should be a better interface for this.
>
>>                                                 - Ted
>>

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

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 1:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> RDSEED is not synchronous.  It is, however, nonblocking.

What I mean is: IIUC it's reasonable to call RDSEED a few times in a
loop and hope it works.  It makes no sense to do that with
/dev/random.

>
> On May 1, 2014 1:16:40 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>>On May 1, 2014 12:26 PM, <tytso@mit.edu> wrote:
>>>
>>> On Thu, May 01, 2014 at 12:02:49PM -0700, Andy Lutomirski wrote:
>>> >
>>> > Is RDSEED really reasonable here?  Won't it slow down by several
>>> > orders of magnitude?
>>>
>>> That is I think the biggest problem; RDRAND and RDSEED are fast if
>>> they are native, but they will involve a VM exit if they need to be
>>> emulated.  So when an OS might want to use RDRAND and RDSEED might be
>>> quite different if we know they are being emulated.
>>>
>>> Using the RDRAND and RDSEED "api" certainly makes sense, at least for
>>> x86, but I suspect we might want to use a different way of signalling
>>> that a VM guest can use RDRAND and RDSEED if they are running on a
>>CPU
>>> which doesn't provide that kind of access.  Maybe a CPUID extended
>>> function parameter, if one could be allocated for use by a Linux
>>> hypervisor?
>>>
>>
>>I'm still not convinced.  This will affect userspace as well as the
>>guest kernel, and I don't see why guest user code should be able to
>>access this API.  RDRAND for CPL0 only would work, but that seems odd.
>>
>>And I think that RDSEED emulation is asking for trouble.  RDSEED is
>>synchronous, but /dev/random is asynchronous.  And making bootup wait
>>for even a single byte from /dev/random seems bad.  In any event,
>>virtio-rng should be a better interface for this.
>>
>>>                                                 - Ted
>>>
>
> --
> Sent from my mobile phone.  Please pardon brevity and lack of formatting.



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: random: Providing a seed value to VM guests

[tytso]

On Thu, May 01, 2014 at 01:32:55PM -0700, Andy Lutomirski wrote:
> On Thu, May 1, 2014 at 1:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> > RDSEED is not synchronous.  It is, however, nonblocking.
> 
> What I mean is: IIUC it's reasonable to call RDSEED a few times in a
> loop and hope it works.  It makes no sense to do that with
> /dev/random.

RDSEED is allowed to return an error if there is insufficient entropy.
So long as the caller understands that this is an emulated
instruction, I don't see a problem.

						- Ted

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 1:39 PM,  <tytso@mit.edu> wrote:
> On Thu, May 01, 2014 at 01:32:55PM -0700, Andy Lutomirski wrote:
>> On Thu, May 1, 2014 at 1:30 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> > RDSEED is not synchronous.  It is, however, nonblocking.
>>
>> What I mean is: IIUC it's reasonable to call RDSEED a few times in a
>> loop and hope it works.  It makes no sense to do that with
>> /dev/random.
>
> RDSEED is allowed to return an error if there is insufficient entropy.
> So long as the caller understands that this is an emulated
> instruction, I don't see a problem.

What's the point?

I think this is too caught up in x86 architectural stuff.  As I see
it, the goal is to give guests a way to ask their hosts to give them,
immediately and synchronously, some bytes suitable for seeding an RNG.
 These bytes need not contain true entropy, because the host may not
be able to provide entropy an a timely manner.  The mechanism should
be usable extremely early after boot, it should be usable after a
guest reboot, and it should be reliable.  I think there's an added
benefit if all architectures can implement a semantically equivalent
function, even if the interface is completely different.

There's no need for anything new to provide asynchronous and-or very
slow true random data -- virtio-rng already exists. *

Emulating RDRAND for this purpose is a little weird because it's
normally available to user code and it has the flag indicating
failure.  We're also not going to want the guest kernel to access it
through the arch_get_random interface.

Even if we could emulate RDSEED effectively**, I don't really
understand what the guest is expected to do with it.  And I generally
dislike defining an interface with no known sensible users, because it
means that there's a good chance that the interface won't end up
working.

* I still don't know why it doesn't work for me.  I'll fiddle with it,
but I think that the right solution is to fix it for this purpose, not
to replace it.
** Doing this sensibly in the host will be awkward.  Is the host
supposed to use non-blocking reads of /dev/random?  Getting anything
remotely fair may be difficult.

>
>                                                 - Ted



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

On 05/01/2014 01:56 PM, Andy Lutomirski wrote:
> 
> Even if we could emulate RDSEED effectively**, I don't really
> understand what the guest is expected to do with it.  And I generally
> dislike defining an interface with no known sensible users, because it
> means that there's a good chance that the interface won't end up
> working.
>
> ** Doing this sensibly in the host will be awkward.  Is the host
> supposed to use non-blocking reads of /dev/random?  Getting anything
> remotely fair may be difficult.

The host can use nonblocking reads of /dev/random.  Fairness would have
to be implemented at the host level, but that is true for anything.

	-hpa

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 2:01 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/01/2014 01:56 PM, Andy Lutomirski wrote:
>>
>> Even if we could emulate RDSEED effectively**, I don't really
>> understand what the guest is expected to do with it.  And I generally
>> dislike defining an interface with no known sensible users, because it
>> means that there's a good chance that the interface won't end up
>> working.
>>
>> ** Doing this sensibly in the host will be awkward.  Is the host
>> supposed to use non-blocking reads of /dev/random?  Getting anything
>> remotely fair may be difficult.
>
> The host can use nonblocking reads of /dev/random.  Fairness would have
> to be implemented at the host level, but that is true for anything.
>

I still don't see the point.  What does this do better than virtio-rng?

The ASLR code doesn't even try to use RDSEED.  RDSEED is used in
add_interrupt_randomness, which should drain the host's /dev/random
even if it could, and it's used in init_std_data.  The logic there is:

                if (!arch_get_random_seed_long(&rv) &&
                    !arch_get_random_long(&rv))
                        rv = random_get_entropy();

I think this is better achieved by having the host try to supply the
highest quality data it can.

The third RDSEED use is arch_random_refill.  This purpose would be
much better served by the khwrng stuff and virtio-rng.

So I still claim that fancy emulated RDSEED support will have no users.

--Andy

Re: random: Providing a seed value to VM guests

[tytso]

On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
> 
> I still don't see the point.  What does this do better than virtio-rng?

I believe you had been complaining about how complicated it was to set
up virtio?  And this complexity is also an issue if we want to use it
to initialize the RNG used for the kernel text ASLR --- which has to
be done very early in the boot process, and where making something as
simple as possible is a Good Thing.

And since we would want to use RDRAND/RDSEED if it is available
*anyway*, perhaps in combination with other things, why not use the
RDRAND/RDSEED interface?

							- Ted

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 3:28 PM,  <tytso@mit.edu> wrote:
> On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
>>
>> I still don't see the point.  What does this do better than virtio-rng?
>
> I believe you had been complaining about how complicated it was to set
> up virtio?  And this complexity is also an issue if we want to use it
> to initialize the RNG used for the kernel text ASLR --- which has to
> be done very early in the boot process, and where making something as
> simple as possible is a Good Thing.

It's complicated, so it won't be up until much later in the boot
process.  This is completely fine for /dev/random, but it's a problem
for /dev/urandom, ASLR, and such.

>
> And since we would want to use RDRAND/RDSEED if it is available
> *anyway*, perhaps in combination with other things, why not use the
> RDRAND/RDSEED interface?

Because it's awkward.  I don't think it simplifies anything.

--Andy

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

On 05/01/2014 03:32 PM, Andy Lutomirski wrote:
> On Thu, May 1, 2014 at 3:28 PM,  <tytso@mit.edu> wrote:
>> On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
>>>
>>> I still don't see the point.  What does this do better than virtio-rng?
>>
>> I believe you had been complaining about how complicated it was to set
>> up virtio?  And this complexity is also an issue if we want to use it
>> to initialize the RNG used for the kernel text ASLR --- which has to
>> be done very early in the boot process, and where making something as
>> simple as possible is a Good Thing.
> 
> It's complicated, so it won't be up until much later in the boot
> process.  This is completely fine for /dev/random, but it's a problem
> for /dev/urandom, ASLR, and such.
> 
>>
>> And since we would want to use RDRAND/RDSEED if it is available
>> *anyway*, perhaps in combination with other things, why not use the
>> RDRAND/RDSEED interface?
> 
> Because it's awkward.  I don't think it simplifies anything.
> 

It greatly simplifies discovery, which is a Big Deal[TM] in early code.

	-hpa

Re: random: Providing a seed value to VM guests

[Andy Lutomirski]

On Thu, May 1, 2014 at 3:46 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 05/01/2014 03:32 PM, Andy Lutomirski wrote:
>> On Thu, May 1, 2014 at 3:28 PM,  <tytso@mit.edu> wrote:
>>> On Thu, May 01, 2014 at 02:06:13PM -0700, Andy Lutomirski wrote:
>>>>
>>>> I still don't see the point.  What does this do better than virtio-rng?
>>>
>>> I believe you had been complaining about how complicated it was to set
>>> up virtio?  And this complexity is also an issue if we want to use it
>>> to initialize the RNG used for the kernel text ASLR --- which has to
>>> be done very early in the boot process, and where making something as
>>> simple as possible is a Good Thing.
>>
>> It's complicated, so it won't be up until much later in the boot
>> process.  This is completely fine for /dev/random, but it's a problem
>> for /dev/urandom, ASLR, and such.
>>
>>>
>>> And since we would want to use RDRAND/RDSEED if it is available
>>> *anyway*, perhaps in combination with other things, why not use the
>>> RDRAND/RDSEED interface?
>>
>> Because it's awkward.  I don't think it simplifies anything.
>>
>
> It greatly simplifies discovery, which is a Big Deal[TM] in early code.

I think we're comparing:

a) cpuid to detect rdrand *or* emulated rdrand followed by rdrand

to

b) cpuid to detect rdrand or the paravirt seed msr/cpuid call,
followed by rdrand or the msr or cpuid read

this seems like it barely makes a difference, especially since (a)
probably requires detecting KVM anyway.


For the real kernel code, it's probably even closer to making no
difference, since I don't think we'll want arch_get_random_long to use
emulated rdrand.

--Andy

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

On 05/01/2014 03:56 PM, Andy Lutomirski wrote:
> 
> I think we're comparing:
> 
> a) cpuid to detect rdrand *or* emulated rdrand followed by rdrand
> 
> to
> 
> b) cpuid to detect rdrand or the paravirt seed msr/cpuid call,
> followed by rdrand or the msr or cpuid read
> 
> this seems like it barely makes a difference, especially since (a)
> probably requires detecting KVM anyway.

Well, it lets one do something like:

	if (boot_cpu_has(X86_FEATURE_RDRAND) ||
            boot_cpu_has(X86_FEATURE_RDRAND_SIMULATED))
		rdrand_long(...);

We need the ifs anyway for early code; the arch_*() interfaces are only
available after alternatives run.

	-hpa

Re: random: Providing a seed value to VM guests

[H. Peter Anvin]

The normal CPUID bit is unset I believe.

On May 1, 2014 12:02:49 PM PDT, Andy Lutomirski <luto@amacapital.net> wrote:
>On Thu, May 1, 2014 at 11:59 AM, H. Peter Anvin <hpa@zytor.com> wrote:
>> 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.
>
>Do existing kernels and userspace respect this?  If the normal bit for
>RDRAND is unset, then we might be okay, but, if not, then I think this
>may kill guest performance.
>
>Is RDSEED really reasonable here?  Won't it slow down by several
>orders of magnitude?
>
>>
>>> What's the right forum for this?  This thread is probably not it.
>>
>> Change the subject line?
>
>:)
>
>>
>>         -hpa
>>
>>

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