mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "M Macnair" <mmacnair@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Seeding /dev/random not working
Date: Tue, 29 May 2007 12:53:10 +0100	[thread overview]
Message-ID: <de6d2b4f0705290453kec2b050pb4d0bebc256b87a5@mail.gmail.com> (raw)

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

             reply	other threads:[~2007-05-29 11:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-29 11:53 M Macnair [this message]
2007-05-29 13:15 ` Theodore Tso
2007-05-29 13:38   ` M Macnair
2007-05-29 14:14   ` Pavel Machek
2007-05-29 15:17     ` M Macnair
2007-05-29 15:31       ` Jesper Juhl
2007-05-29 16:30     ` Theodore Tso
2007-05-29 20:06     ` Folkert van Heusden
2007-05-29 17:46   ` Matt Mackall
2007-05-29 18:00     ` Matt Mackall
2007-05-29 19:23     ` Eric Dumazet
2007-05-29 19:35       ` Matt Mackall
2007-05-29 16:58 ` Andi Kleen
2007-05-29 16:44   ` M Macnair
2007-05-29 20:23     ` Matt Mackall
2007-05-29 22:08       ` Andi Kleen
2007-05-29 21:44         ` Matt Mackall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=de6d2b4f0705290453kec2b050pb4d0bebc256b87a5@mail.gmail.com \
    --to=mmacnair@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®