[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sat, 23 Jun 2001 02:14:27 +0200
On Fri, Jun 22, 2001 at 07:51:06PM -0400, Roland McGrath wrote:
> The way character devices normally work is to return whatever is available
> as soon as it is available to whomever is ready to take it first.
OK, just wanted to make sure.
> > * If select returns, how do I guarantee that some random data is
> > available at the next read?
> You only have to guarantee that the next read on the device works. If
> there are multiple readers, then it's their problem to race to get their
> io_read in first and either block or miss out if they don't get it.
> > BTW, there is a fast operation mode, which has not those issues, as it can
> > never block. A switch will enable that, and this will be used for
> > /dev/urandom.
> I presume you mean this synthesizes pseudorandom data from old true
> randomness, as Linux's /dev/urandom does.
Yes. There are actually two levels we can use. Level 0 never cares much
about real randomness. It uses time() and getrusage() to gather the
randomness and nothing else. Level 1 is more useful, it will take good
random data if it is available, but will not block if there isn't any.
I think I can expose the level as an argument option to the translator (to
be exact, three arguments with symbolic names). Level 1 would just poll
/dev/random in O_NONBLOCK mode.
> It would be good to have a read-only kernel "random" device too. This
> would collect the various low-level sources of entropy (interrupt timings,
> etc) that kernel device drivers contribute in Linux and BSD.
I did include it in my gnumach character device port. It was the first one
which worked, actually. I could revive the patch, but we all know it is the
wrong way to go. What is the story with character devices in OSKit?
> I guess the translator could just have general support for reading from
> character devices of true randomness, and then the kernel device would just
> use a vanilla streamio translator and that would be one of the input files.
Yes, there could be a worker thread gathering random from various sources.
It could even make an attempt to query vmstat etc for some random (there
already exists such a thing as a plugin in gnupg). The one issue there is
that you'd want it to run as early as possible, so you'd want to wake up
/dev/random at startup. I thought it would be nice to have egd write to
/dev/random, as this would automatically start the active translator as
well, but /dev/random polling from some fifo would also work of course.
There is also a nice feature of writing a seed file. This will be
absolutely cool together with the shutdown notification.
`Rhubarb is no Egyptian god.' Debian http://www.debian.org address@hidden
Marcus Brinkmann GNU http://www.gnu.org address@hidden