Seeding /dev/random not working

Seeding /dev/random not working

[M Macnair]

In brief: Adding entropy by writing to /dev/[u]random doesn't appear
to be working.  I am aware that the reported available entropy (via
/proc/sys/kernel/random/entropy_avail) will not increase; the symptom
is /dev/random keeps spitting out the same numbers.

I have two embedded boards (one ARM, one PowerPC), running two
different versions of 2.6.  They have no hard drives, keyboards or
mice.  They each have a NIC, but I understand these make no
contribution to the entropy pool.

Many distros ship with an init script that saves and restores the
entropy pool on startup and shutdown.  The bit that interests me that
is called on startup is (my comments):
	if [ -f $random_seed ]; then
		cat $random_seed >/dev/urandom  # should seed the pool
	fi
	dd if=/dev/urandom of=$random_seed count=1 2>/dev/null # save some
data from urandom for next boot
I have rebooted my boards many times, and after each boot I read the
contents of $random_seed.  Whilst it does not happen every time, the
contents of $random_seed are /often the same/.  To give you a feel:
rebooted 11 times, got a total of 3 different outputs.

This suggests that cat'ing the contents of the random_seed file into
/dev/urandom is not actually increasing the available entropy at all;
indeed it is having no effect whatsoever.

This is obviously a serious issue on these boards, as writing to
/dev/random is the only source of entropy.

In place of these startup scripts I have tried my own script that
explicitly cats in a load of data, and then reads out several K from
/dev/urandom - the data that is read out is normally the same, no
matter what data is written.

I put the fact that this is not 100% reproducible down to timing
variations, which is also the reason why all the experimentation has
been done at startup - the reading and writing occurs at very nearly
exactly the same kernel time, every time it boots.

Is this a bug?  Am I doing something stupid?

Thanks,
Michael Macnair

Re: Seeding /dev/random not working

[Theodore Tso]

On Tue, May 29, 2007 at 12:53:10PM +0100, M Macnair wrote:
> I have two embedded boards (one ARM, one PowerPC), running two
> different versions of 2.6.  They have no hard drives, keyboards or
> mice.  They each have a NIC, but I understand these make no
> contribution to the entropy pool.
> 
> 	if [ -f $random_seed ]; then
> 		cat $random_seed >/dev/urandom  # should seed the pool
> 	fi
> 	dd if=/dev/urandom of=$random_seed count=1 2>/dev/null # save some
> data from urandom for next boot
>
> I have rebooted my boards many times, and after each boot I read the
> contents of $random_seed.  Whilst it does not happen every time, the
> contents of $random_seed are /often the same/.  To give you a feel:
> rebooted 11 times, got a total of 3 different outputs.

Ok, so this is telling me a couple of things.  First of all, if you're
only getting three outputs, it means that you don't have any
peripherals feeding entropy into the system from the boot sequence.
Without any hard drives, keyboards or mice, and a NIC whose device
driver hasn't been configured to feed entropy, you're definitely
hosed.

Secondly, and more importantly, your boot scripts aren't set up
correctly.  You really want to make sure that you save the some
entropy at shutdown.  i.e., run at shutdown the same sequence that was
run at the boot-time.  (You don't really need the "cat $random_seed >
/dev/urandom", but it's harmless.)  Repeating this sequence at
shutdown is useful because it saves any entropy gathered from the
current boot session and saves it to be used at the next boot session.
I've noticed a number of distro's have gotten this wrong, and I guess
I should have filed more bugs to get this fixed.  In your case, since
you don't have anything wired up to feed entropy into your pool, it
will make /dev/urandom effectively a psuedo-random number generator,
but at least you won't get repeating outputs.

Another thing which I noticed is that when Matt Mackall took over
maintainership of /dev/random, he apparently took out one of the
safeguards I had, which was that before, when entropy was extracted
from the pool the time stamp when it was extracted was mixed back into
the pool.  The theory was that an external attacker might not know
when a program might be calling /dev/random, so mixing in the time of
that entropy was extracted wouldn't hurt, and might help.  I'll submit
a patch to add that support back in, which will help you a little.

HOWEVER, the more important thing to remember is that /dev/random
isn't magic.  If you don't have any entropy sources to mix in, and you
don't do anything at the application level to mix in data that might
not be known by external attackers, you will always be vulnerable,
especially if your threat model includes government funded
intelligence agencies.  So if you are planning on using /dev/urandom
for cryptographic purposes, while some of these fixes will avoid at
least the embarassing result of repeating outputs from /dev/urandom,
it's not really going to result in high-quality unpredictable results
against a well-funded, determined adversary.  

If that is your threat model, then you really should consider adding
hardware random number generator into your product design.

Regards,

					- Ted

Re: Seeding /dev/random not working

[M Macnair]

On 5/29/07, Theodore Tso <tytso@mit.edu> wrote:
> On Tue, May 29, 2007 at 12:53:10PM +0100, M Macnair wrote:
> Ok, so this is telling me a couple of things.  First of all, if you're
> only getting three outputs, it means that you don't have any
> peripherals feeding entropy into the system from the boot sequence.
> Without any hard drives, keyboards or mice, and a NIC whose device
> driver hasn't been configured to feed entropy, you're definitely
> hosed.

Yes.  However this isn't the issue I'm concerned with at the moment.

> Secondly, and more importantly, your boot scripts aren't set up
> correctly.

Sorry, I only posted the startup bit - the same does indeed happen on
shutdown, however I wasn't interested in it for the purposes of the
tests.

The key point I was trying to put across was that I can't get the
seeding process to work.  No matter what I wrote to /dev/urandom on
startup, the output from reading /dev/urandom immediately afterwards
was the same (ignoring the occasional variation that I put down to
timing).  As I understand it (from man 4 random and the boot script
examples), writing to /dev/[u]random should increase the amount of
entropy, thereby altering the output from the PRNG.

> Another thing which I noticed is that when Matt Mackall took over
> maintainership of /dev/random, he apparently took out one of the
> safeguards I had, which was that before, when entropy was extracted
> from the pool the time stamp when it was extracted was mixed back into
> the pool.  The theory was that an external attacker might not know
> when a program might be calling /dev/random, so mixing in the time of
> that entropy was extracted wouldn't hurt, and might help.  I'll submit
> a patch to add that support back in, which will help you a little.

When did Matt take over?  From my experiments it would appear as
though the time is having an effect on the output, though as I say I'm
not totally sure.

Regards,
Michael Macnair

Re: Seeding /dev/random not working

[Pavel Machek]

Hi!

> > I have two embedded boards (one ARM, one PowerPC), running two
> > different versions of 2.6.  They have no hard drives, keyboards or
> > mice.  They each have a NIC, but I understand these make no
> > contribution to the entropy pool.
> > 
> > 	if [ -f $random_seed ]; then
> > 		cat $random_seed >/dev/urandom  # should seed the pool
> > 	fi
> > 	dd if=/dev/urandom of=$random_seed count=1 2>/dev/null # save some
> > data from urandom for next boot
> >
> > I have rebooted my boards many times, and after each boot I read the
> > contents of $random_seed.  Whilst it does not happen every time, the
> > contents of $random_seed are /often the same/.  To give you a feel:
> > rebooted 11 times, got a total of 3 different outputs.
> 
> Ok, so this is telling me a couple of things.  First of all, if you're
> only getting three outputs, it means that you don't have any
> peripherals feeding entropy into the system from the boot sequence.
> Without any hard drives, keyboards or mice, and a NIC whose device
> driver hasn't been configured to feed entropy, you're definitely
> hosed.

Can we get at least time-of-boot from rtc clock to the pool? We really
should not be getting identical outputs...

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: Seeding /dev/random not working

[M Macnair]

On 5/29/07, Pavel Machek <pavel@ucw.cz> wrote:
> Hi!
>
> > > I have two embedded boards (one ARM, one PowerPC), running two
> > > different versions of 2.6.  They have no hard drives, keyboards or
> > > mice.  They each have a NIC, but I understand these make no
> > > contribution to the entropy pool.
> > >
> > >     if [ -f $random_seed ]; then
> > >             cat $random_seed >/dev/urandom  # should seed the pool
> > >     fi
> > >     dd if=/dev/urandom of=$random_seed count=1 2>/dev/null # save some
> > > data from urandom for next boot
> > >
> > > I have rebooted my boards many times, and after each boot I read the
> > > contents of $random_seed.  Whilst it does not happen every time, the
> > > contents of $random_seed are /often the same/.  To give you a feel:
> > > rebooted 11 times, got a total of 3 different outputs.
> >
> > Ok, so this is telling me a couple of things.  First of all, if you're
> > only getting three outputs, it means that you don't have any
> > peripherals feeding entropy into the system from the boot sequence.
> > Without any hard drives, keyboards or mice, and a NIC whose device
> > driver hasn't been configured to feed entropy, you're definitely
> > hosed.
>
> Can we get at least time-of-boot from rtc clock to the pool? We really
> should not be getting identical outputs...

Ah yes that is one thing I forgot to mention - when you turn these
boards off, you really do turn them off - no battery means no clock.
They wake up every time in 1970.

I am planning on providing my own entropy to this system by feeding
/dev/random (which leads to the problem of it not working...).

Re: Seeding /dev/random not working

[Jesper Juhl]

On 29/05/07, M Macnair <mmacnair@gmail.com> wrote:
> On 5/29/07, Pavel Machek <pavel@ucw.cz> wrote:
> > Hi!
> >
> > > > I have two embedded boards (one ARM, one PowerPC), running two
> > > > different versions of 2.6.  They have no hard drives, keyboards or
> > > > mice.  They each have a NIC, but I understand these make no
> > > > contribution to the entropy pool.
> > > >
> > > >     if [ -f $random_seed ]; then
> > > >             cat $random_seed >/dev/urandom  # should seed the pool
> > > >     fi
> > > >     dd if=/dev/urandom of=$random_seed count=1 2>/dev/null # save some
> > > > data from urandom for next boot
> > > >
> > > > I have rebooted my boards many times, and after each boot I read the
> > > > contents of $random_seed.  Whilst it does not happen every time, the
> > > > contents of $random_seed are /often the same/.  To give you a feel:
> > > > rebooted 11 times, got a total of 3 different outputs.
> > >
> > > Ok, so this is telling me a couple of things.  First of all, if you're
> > > only getting three outputs, it means that you don't have any
> > > peripherals feeding entropy into the system from the boot sequence.
> > > Without any hard drives, keyboards or mice, and a NIC whose device
> > > driver hasn't been configured to feed entropy, you're definitely
> > > hosed.
> >
> > Can we get at least time-of-boot from rtc clock to the pool? We really
> > should not be getting identical outputs...
>
> Ah yes that is one thing I forgot to mention - when you turn these
> boards off, you really do turn them off - no battery means no clock.
> They wake up every time in 1970.
>
> I am planning on providing my own entropy to this system by feeding
> /dev/random (which leads to the problem of it not working...).

Depending on how high quality randomness you need, you could just let
your NIC driver provide entropy by changing interrupt handlers to use
SA_SAMPLE_RANDOM.
Sure, getting entropy that way allows an outside attacker to influence
the pool if they can obtain a high degree of control over what data
you recieve and when, but in most realistic scenarios it should be
acceptable (and it's certainly better than no entropy at all).

-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: Seeding /dev/random not working

[Theodore Tso]

On Tue, May 29, 2007 at 02:14:56PM +0000, Pavel Machek wrote:
> Can we get at least time-of-boot from rtc clock to the pool? We really
> should not be getting identical outputs...

We are mixing the time-of-dat at boot time into the pool already,
using ktime_get_real() in random.c:init_std_data().  The problem
though is if the board doesn't have a valid RTC clock, or its battery
is dead, and the time-of-day clock is getting set by userspace, then
unless userspace also mixes in the time once it's been set via ntpdate
or whatever, it won't help the entropy pool.

						- Ted

Re: Seeding /dev/random not working

[Folkert van Heusden]

> > > I have two embedded boards (one ARM, one PowerPC), running two
> > > different versions of 2.6.  They have no hard drives, keyboards or
> > > mice.  They each have a NIC, but I understand these make no
> > > contribution to the entropy pool.
> > > 	if [ -f $random_seed ]; then
> > > 		cat $random_seed >/dev/urandom  # should seed the pool
> > > 	fi
> > > 	dd if=/dev/urandom of=$random_seed count=1 2>/dev/null # save some
> > > data from urandom for next boot
> > > I have rebooted my boards many times, and after each boot I read the
> > > contents of $random_seed.  Whilst it does not happen every time, the
> > > contents of $random_seed are /often the same/.  To give you a feel:
> > > rebooted 11 times, got a total of 3 different outputs.
> > 
> > Ok, so this is telling me a couple of things.  First of all, if you're
> > only getting three outputs, it means that you don't have any
> > peripherals feeding entropy into the system from the boot sequence.
> > Without any hard drives, keyboards or mice, and a NIC whose device
> > driver hasn't been configured to feed entropy, you're definitely
> > hosed.
> 
> Can we get at least time-of-boot from rtc clock to the pool? We really
> should not be getting identical outputs...

And add readings from lm-sensors as well? I guess harddisk and cpu
temperatures (lower bits) and such are pretty random?


Folkert van Heusden

-- 
MultiTail est un flexible tool pour suivre de logfiles et execution de
commandements. Filtrer, pourvoir de couleur, merge, 'diff-view', etc.
http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Re: Seeding /dev/random not working

[Matt Mackall]

On Tue, May 29, 2007 at 09:15:01AM -0400, Theodore Tso wrote:
> Another thing which I noticed is that when Matt Mackall took over
> maintainership of /dev/random, he apparently took out one of the
> safeguards I had, which was that before, when entropy was extracted
> from the pool the time stamp when it was extracted was mixed back into
> the pool.  The theory was that an external attacker might not know
> when a program might be calling /dev/random, so mixing in the time of
> that entropy was extracted wouldn't hurt, and might help.  I'll submit
> a patch to add that support back in, which will help you a little.

It's still there, and in the same place, it just looks different:

static void add_timer_randomness(struct timer_rand_state *state,
unsigned num)
{
...
        sample.jiffies = jiffies;
        sample.cycles = get_cycles();
        sample.num = num;
        add_entropy_words(&input_pool, (u32 *)&sample,
	sizeof(sample)/4);

Trouble is the write(2) interface calls add_entropy_words directly, as
does the pool initialization function.

We might as well mix jiffies and cycles in at init time in a manner
similar to the above. Something like this (untested):

Index: l/drivers/char/random.c
===================================================================
--- l.orig/drivers/char/random.c	2007-05-29 12:45:00.000000000 -0500
+++ l/drivers/char/random.c	2007-05-29 12:44:02.000000000 -0500
@@ -559,6 +559,26 @@ static struct timer_rand_state input_tim
 static struct timer_rand_state *irq_timer_state[NR_IRQS];
 
 /*
+ * Mix a sample of the current time into the pool with no entropy
+ * accounting
+ */
+static long __add_timer_randomness(void)
+{
+	struct {
+		cycles_t cycles;
+		long jiffies;
+		unsigned num;
+	} sample;
+
+	sample.jiffies = jiffies;
+	sample.cycles = get_cycles();
+	sample.num = num;
+	add_entropy_words(&input_pool, (u32 *)&sample, sizeof(sample)/4);
+
+	return sample.jiffies;
+}
+
+/*
  * This function adds entropy to the entropy "pool" by using timing
  * delays.  It uses the timer_rand_state structure to make an estimate
  * of how many bits of entropy this call has added to the pool.
@@ -570,12 +590,7 @@ static struct timer_rand_state *irq_time
  */
 static void add_timer_randomness(struct timer_rand_state *state, unsigned num)
 {
-	struct {
-		cycles_t cycles;
-		long jiffies;
-		unsigned num;
-	} sample;
-	long delta, delta2, delta3;
+	long timestamp, delta, delta2, delta3;
 
 	preempt_disable();
 	/* if over the trickle threshold, use only 1 in 4096 samples */
@@ -583,10 +598,7 @@ static void add_timer_randomness(struct 
 	    (__get_cpu_var(trickle_count)++ & 0xfff))
 		goto out;
 
-	sample.jiffies = jiffies;
-	sample.cycles = get_cycles();
-	sample.num = num;
-	add_entropy_words(&input_pool, (u32 *)&sample, sizeof(sample)/4);
+	timestamp = __add_timer_randomness();
 
 	/*
 	 * Calculate number of bits of randomness we probably added.
@@ -595,8 +607,8 @@ static void add_timer_randomness(struct 
 	 */
 
 	if (!state->dont_count_entropy) {
-		delta = sample.jiffies - state->last_time;
-		state->last_time = sample.jiffies;
+		delta = timestamp - state->last_time;
+		state->last_time = timestamp;
 
 		delta2 = delta - state->last_delta;
 		state->last_delta = delta;
@@ -899,6 +911,7 @@ static int __init rand_initialize(void)
 	init_std_data(&input_pool);
 	init_std_data(&blocking_pool);
 	init_std_data(&nonblocking_pool);
+	__add_timer_randomness();
 	return 0;
 }
 module_init(rand_initialize);
@@ -1028,6 +1041,8 @@ random_write(struct file * file, const c
 	const char __user *p = buffer;
 	size_t c = count;
 
+	__add_timer_randomness();
+
 	while (c > 0) {
 		bytes = min(c, sizeof(buf));
 


-- 
Mathematics is the supreme nostalgia of our time.

Re: Seeding /dev/random not working

[Matt Mackall]

On Tue, May 29, 2007 at 12:46:14PM -0500, Matt Mackall wrote:
> We might as well mix jiffies and cycles in at init time in a manner
> similar to the above. Something like this (untested):

Scratch that one. Here's one that compiles and seems to work under
lguest:

Index: l/drivers/char/random.c
===================================================================
--- l.orig/drivers/char/random.c	2007-05-29 12:45:00.000000000 -0500
+++ l/drivers/char/random.c	2007-05-29 12:50:02.000000000 -0500
@@ -559,6 +559,26 @@ static struct timer_rand_state input_tim
 static struct timer_rand_state *irq_timer_state[NR_IRQS];
 
 /*
+ * Mix a sample of the current time into the pool with no entropy
+ * accounting
+ */
+static long __add_timer_randomness(unsigned num)
+{
+	struct {
+		cycles_t cycles;
+		long jiffies;
+		unsigned num;
+	} sample;
+
+	sample.jiffies = jiffies;
+	sample.cycles = get_cycles();
+	sample.num = num;
+	add_entropy_words(&input_pool, (u32 *)&sample, sizeof(sample)/4);
+
+	return sample.jiffies;
+}
+
+/*
  * This function adds entropy to the entropy "pool" by using timing
  * delays.  It uses the timer_rand_state structure to make an estimate
  * of how many bits of entropy this call has added to the pool.
@@ -570,12 +590,7 @@ static struct timer_rand_state *irq_time
  */
 static void add_timer_randomness(struct timer_rand_state *state, unsigned num)
 {
-	struct {
-		cycles_t cycles;
-		long jiffies;
-		unsigned num;
-	} sample;
-	long delta, delta2, delta3;
+	long timestamp, delta, delta2, delta3;
 
 	preempt_disable();
 	/* if over the trickle threshold, use only 1 in 4096 samples */
@@ -583,10 +598,7 @@ static void add_timer_randomness(struct 
 	    (__get_cpu_var(trickle_count)++ & 0xfff))
 		goto out;
 
-	sample.jiffies = jiffies;
-	sample.cycles = get_cycles();
-	sample.num = num;
-	add_entropy_words(&input_pool, (u32 *)&sample, sizeof(sample)/4);
+	timestamp = __add_timer_randomness(num);
 
 	/*
 	 * Calculate number of bits of randomness we probably added.
@@ -595,8 +607,8 @@ static void add_timer_randomness(struct 
 	 */
 
 	if (!state->dont_count_entropy) {
-		delta = sample.jiffies - state->last_time;
-		state->last_time = sample.jiffies;
+		delta = timestamp - state->last_time;
+		state->last_time = timestamp;
 
 		delta2 = delta - state->last_delta;
 		state->last_delta = delta;
@@ -899,6 +911,7 @@ static int __init rand_initialize(void)
 	init_std_data(&input_pool);
 	init_std_data(&blocking_pool);
 	init_std_data(&nonblocking_pool);
+	__add_timer_randomness(0);
 	return 0;
 }
 module_init(rand_initialize);
@@ -1028,6 +1041,8 @@ random_write(struct file * file, const c
 	const char __user *p = buffer;
 	size_t c = count;
 
+	__add_timer_randomness(0);
+
 	while (c > 0) {
 		bytes = min(c, sizeof(buf));
 

-- 
Mathematics is the supreme nostalgia of our time.

Re: Seeding /dev/random not working

[Eric Dumazet]

Matt Mackall a écrit :
> On Tue, May 29, 2007 at 09:15:01AM -0400, Theodore Tso wrote:
>> Another thing which I noticed is that when Matt Mackall took over
>> maintainership of /dev/random, he apparently took out one of the
>> safeguards I had, which was that before, when entropy was extracted
>> from the pool the time stamp when it was extracted was mixed back into
>> the pool.  The theory was that an external attacker might not know
>> when a program might be calling /dev/random, so mixing in the time of
>> that entropy was extracted wouldn't hurt, and might help.  I'll submit
>> a patch to add that support back in, which will help you a little.
> 
> It's still there, and in the same place, it just looks different:
> 
> static void add_timer_randomness(struct timer_rand_state *state,
> unsigned num)
> {
> ...
>         sample.jiffies = jiffies;
>         sample.cycles = get_cycles();
>         sample.num = num;
>         add_entropy_words(&input_pool, (u32 *)&sample,
> 	sizeof(sample)/4);
> 
> Trouble is the write(2) interface calls add_entropy_words directly, as
> does the pool initialization function.
> 
> We might as well mix jiffies and cycles in at init time in a manner
> similar to the above. Something like this (untested):
> 
> Index: l/drivers/char/random.c
> ===================================================================
> --- l.orig/drivers/char/random.c	2007-05-29 12:45:00.000000000 -0500
> +++ l/drivers/char/random.c	2007-05-29 12:44:02.000000000 -0500
> @@ -559,6 +559,26 @@ static struct timer_rand_state input_tim
>  static struct timer_rand_state *irq_timer_state[NR_IRQS];
>  
>  /*
> + * Mix a sample of the current time into the pool with no entropy
> + * accounting
> + */
> +static long __add_timer_randomness(void)
> +{
> +	struct {
> +		cycles_t cycles;
> +		long jiffies;
> +		unsigned num;
> +	} sample;
> +
> +	sample.jiffies = jiffies;
> +	sample.cycles = get_cycles();
> +	sample.num = num;
> +	add_entropy_words(&input_pool, (u32 *)&sample, sizeof(sample)/4);

Well, you need to pass 'num' argument I guess.

But... How is this supposed to work on 64 bits arches ?

Because of alignment, 'struct sample' will include a 4 bytes filler after 
'unsigned num', and sizeof(sample) will include this (null) filler in entropy 
pool.

Shouldn't we use __attribute__((packed)) on 'struct sample' definition ?

Re: Seeding /dev/random not working

[Matt Mackall]

On Tue, May 29, 2007 at 09:23:31PM +0200, Eric Dumazet wrote:
> Matt Mackall a écrit :
> >On Tue, May 29, 2007 at 09:15:01AM -0400, Theodore Tso wrote:
> >>Another thing which I noticed is that when Matt Mackall took over
> >>maintainership of /dev/random, he apparently took out one of the
> >>safeguards I had, which was that before, when entropy was extracted
> >>from the pool the time stamp when it was extracted was mixed back into
> >>the pool.  The theory was that an external attacker might not know
> >>when a program might be calling /dev/random, so mixing in the time of
> >>that entropy was extracted wouldn't hurt, and might help.  I'll submit
> >>a patch to add that support back in, which will help you a little.
> >
> >It's still there, and in the same place, it just looks different:
> >
> >static void add_timer_randomness(struct timer_rand_state *state,
> >unsigned num)
> >{
> >...
> >        sample.jiffies = jiffies;
> >        sample.cycles = get_cycles();
> >        sample.num = num;
> >        add_entropy_words(&input_pool, (u32 *)&sample,
> >	sizeof(sample)/4);
> >
> >Trouble is the write(2) interface calls add_entropy_words directly, as
> >does the pool initialization function.
> >
> >We might as well mix jiffies and cycles in at init time in a manner
> >similar to the above. Something like this (untested):
> >
> >Index: l/drivers/char/random.c
> >===================================================================
> >--- l.orig/drivers/char/random.c	2007-05-29 12:45:00.000000000 -0500
> >+++ l/drivers/char/random.c	2007-05-29 12:44:02.000000000 -0500
> >@@ -559,6 +559,26 @@ static struct timer_rand_state input_tim
> > static struct timer_rand_state *irq_timer_state[NR_IRQS];
> > 
> > /*
> >+ * Mix a sample of the current time into the pool with no entropy
> >+ * accounting
> >+ */
> >+static long __add_timer_randomness(void)
> >+{
> >+	struct {
> >+		cycles_t cycles;
> >+		long jiffies;
> >+		unsigned num;
> >+	} sample;
> >+
> >+	sample.jiffies = jiffies;
> >+	sample.cycles = get_cycles();
> >+	sample.num = num;
> >+	add_entropy_words(&input_pool, (u32 *)&sample, sizeof(sample)/4);
> 
> Well, you need to pass 'num' argument I guess.

Yep, fixed version already posted.
 
> But... How is this supposed to work on 64 bits arches ?
> 
> Because of alignment, 'struct sample' will include a 4 bytes filler after 
> 'unsigned num', and sizeof(sample) will include this (null) filler in 
> entropy pool.

Doesn't matter, just churns the pool a bit more. It gets XORed over
existing data (aka NOP) and doesn't get counted as extra entropy or
anything.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Seeding /dev/random not working

[Andi Kleen]

"M Macnair" <mmacnair@gmail.com> writes:
> 
> Many distros ship with an init script that saves and restores the
> entropy pool on startup and shutdown.  The bit that interests me that
> is called on startup is (my comments):
> 	if [ -f $random_seed ]; then
> 		cat $random_seed >/dev/urandom  # should seed the pool
^[OA
Writing doesn't actually work; to get real accounted entropy for /dev/random
you need to use a special ioctl. I ran into this problem some years ago 
and ended up writing http://www.muc.de/~ak/rndfeed.c

-Andi

Re: Seeding /dev/random not working

[M Macnair]

On 29 May 2007 18:58:59 +0200, Andi Kleen <andi@firstfloor.org> wrote:
> "M Macnair" <mmacnair@gmail.com> writes:
> >
> > Many distros ship with an init script that saves and restores the
> > entropy pool on startup and shutdown.  The bit that interests me that
> > is called on startup is (my comments):
> >       if [ -f $random_seed ]; then
> >               cat $random_seed >/dev/urandom  # should seed the pool
> ^[OA
> Writing doesn't actually work; to get real accounted entropy for /dev/random
> you need to use a special ioctl. I ran into this problem some years ago
> and ended up writing http://www.muc.de/~ak/rndfeed.c
>
> -Andi

If this doesn't work, then it seems to me as though all the
debian-esque distros that use equivalents of the above script are
wasting their time, and the man page recommending that technique (man
4 random) is also wrong.  Is that interpretation correct?

Mike

Re: Seeding /dev/random not working

[Matt Mackall]

On Tue, May 29, 2007 at 05:44:37PM +0100, M Macnair wrote:
> On 29 May 2007 18:58:59 +0200, Andi Kleen <andi@firstfloor.org> wrote:
> >"M Macnair" <mmacnair@gmail.com> writes:
> >>
> >> Many distros ship with an init script that saves and restores the
> >> entropy pool on startup and shutdown.  The bit that interests me that
> >> is called on startup is (my comments):
> >>       if [ -f $random_seed ]; then
> >>               cat $random_seed >/dev/urandom  # should seed the pool
> >^[OA
> >Writing doesn't actually work; to get real accounted entropy for 
> >/dev/random
> >you need to use a special ioctl. I ran into this problem some years ago
> >and ended up writing http://www.muc.de/~ak/rndfeed.c
> >
> >-Andi
> 
> If this doesn't work, then it seems to me as though all the
> debian-esque distros that use equivalents of the above script are
> wasting their time, and the man page recommending that technique (man
> 4 random) is also wrong.  Is that interpretation correct?

Andi is incorrect. Writing does work and everything you write is mixed
into the pool. It's just not counted as entropy credit. This is as
intended.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Seeding /dev/random not working

[Andi Kleen]

Matt Mackall <mpm@selenic.com> writes:

> On Tue, May 29, 2007 at 05:44:37PM +0100, M Macnair wrote:
> > On 29 May 2007 18:58:59 +0200, Andi Kleen <andi@firstfloor.org> wrote:
> > >"M Macnair" <mmacnair@gmail.com> writes:
> > >>
> > >> Many distros ship with an init script that saves and restores the
> > >> entropy pool on startup and shutdown.  The bit that interests me that
> > >> is called on startup is (my comments):
> > >>       if [ -f $random_seed ]; then
> > >>               cat $random_seed >/dev/urandom  # should seed the pool
> > >^[OA
> > >Writing doesn't actually work; to get real accounted entropy for 
> > >/dev/random
> > >you need to use a special ioctl. I ran into this problem some years ago
> > >and ended up writing http://www.muc.de/~ak/rndfeed.c
> > >
> > >-Andi
> > 
> > If this doesn't work, then it seems to me as though all the
> > debian-esque distros that use equivalents of the above script are
> > wasting their time, and the man page recommending that technique (man
> > 4 random) is also wrong.  Is that interpretation correct?
> 
> Andi is incorrect. Writing does work and everything you write is mixed

Note I wrote accounted entropy above.

> into the pool. It's just not counted as entropy credit.

This means everything using /dev/random blocks.  For me that
includes "does not work".

> This is as intended.

If the intention was to get everybody from stopping /dev/random
and moving them to /dev/urandom I guess it works well. Congratulations.

-Andi

Re: Seeding /dev/random not working

[Matt Mackall]

On Wed, May 30, 2007 at 12:08:22AM +0200, Andi Kleen wrote:
> Matt Mackall <mpm@selenic.com> writes:
> 
> > On Tue, May 29, 2007 at 05:44:37PM +0100, M Macnair wrote:
> > > On 29 May 2007 18:58:59 +0200, Andi Kleen <andi@firstfloor.org> wrote:
> > > >"M Macnair" <mmacnair@gmail.com> writes:
> > > >>
> > > >> Many distros ship with an init script that saves and restores the
> > > >> entropy pool on startup and shutdown.  The bit that interests me that
> > > >> is called on startup is (my comments):
> > > >>       if [ -f $random_seed ]; then
> > > >>               cat $random_seed >/dev/urandom  # should seed the pool
> > > >^[OA
> > > >Writing doesn't actually work; to get real accounted entropy for 
> > > >/dev/random
> > > >you need to use a special ioctl. I ran into this problem some years ago
> > > >and ended up writing http://www.muc.de/~ak/rndfeed.c
> > > >
> > > >-Andi
> > > 
> > > If this doesn't work, then it seems to me as though all the
> > > debian-esque distros that use equivalents of the above script are
> > > wasting their time, and the man page recommending that technique (man
> > > 4 random) is also wrong.  Is that interpretation correct?
> > 
> > Andi is incorrect. Writing does work and everything you write is mixed
> 
> Note I wrote accounted entropy above.
> 
> > into the pool. It's just not counted as entropy credit.
> 
> This means everything using /dev/random blocks.  For me that
> includes "does not work".
> 
> > This is as intended.
> 
> If the intention was to get everybody from stopping /dev/random
> and moving them to /dev/urandom I guess it works well. Congratulations.

The intention is to be secure. It's well-known that goal is often in
conflict with being user-friendly. Pretending we have entropy that we
don't is user-friendly but not secure.

And indeed, there's no reason to think there was any entropy in the
pool when we dumped the seed data from /dev/urandom to disk at
shutdown, so there's no reason we should claim there was any there
when we start up. Especially as someone may have looked at that file
in the interim.

Further, congratulations aren't due to me. Linux /dev/random has
gotten this right since day one.

-- 
Mathematics is the supreme nostalgia of our time.