On Friday 04 August 2006 15:00, moreau francis wrote:
> Michael Buesch wrote:
> > The dataflow is as follows:
>
> > HW-RNG -> userspace RNGD (through /dev/hwrng) -> the daemon
> > checks it for sanity and puts it back into the kernel through
> > /dev/random -> Your driver gets the data from the /dev/random
> > entropy pools.
>
> Is that also true for embedded systems ? I mean we may not found
> any rngd on these systems.
Yes, I think so.
> One other question now: suppose that others drivers need to use
> random data during their inits. At this time userspace appli still not
> have been started. How does it work ?
>
> > This is very neccesary, because your HW-RNG may fail and
> > so you may unintentionally use non-random data, if you use
> > the random data from the RNG directly.
> > The data _must_ go through userspace rngd, which does FIPS
> > sanity checks on the data.
>
> Well I'm working on a secure SOC which have a randown hardware
> which is supposed to return true random data. I understand that
> some self tests on the random data are needed but doing them in
> userspace is suprising.
The whole purpose of the hrwng subsystem is to give userspace
an interface to the RNG device. Not more and not less.
So, if you have a special hwrng on your embedded board and you
have some special driver in that board, why not interface
directly from the driver to the hwrng-driver?
This is all pretty special case.
In the hwrng-driver you could still additionally do a
hrwng_register() to export the functionality to
userspace, though.
I am not a friend of a direct in-kernel hwrng access interface,
because it may return crap data by definition. Many (all current)
RNG devices may fail and return non-random data. If that's happily
used by some in-kernel user by the interface, we are screwed.
Why can't you build your random-data consumer as module and load
it later, when random data is available (and was carefully checked
by various tests in rngd)?
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
