Hi
I developped a HW RNG for a custom board and several
other drivers are using it through a special entry I made.
I was planning to move the code in order to use the generic
the RNG layer but I encounter an issue.
Currently it seems not possible for a driver to use HW RNG,
because there's no entry point for that. Is that something
deliberate ?
Another question about the implementation. If O_NONBLOCK
flag is passed when opening /dev/hw_random, how does the
read method ensure that the caller won't sleep since it calls
mutex_lock_interruptible() function unconditiannaly ? I must
miss something but don't know what...
Thanks
Francis
Ar Maw, 2006-08-01 am 12:09 +0000, ysgrifennodd moreau francis:
> Another question about the implementation. If O_NONBLOCK
> flag is passed when opening /dev/hw_random, how does the
> read method ensure that the caller won't sleep since it calls
> mutex_lock_interruptible() function unconditiannaly ? I must
> miss something but don't know what...
O_NONBLOCK doesn't necessarily imply "never sleep", it implies "don't
sleep waiting for an event/long time". So where the mutex is just
serializing access to hardware that will be very brief it is fine not to
check O_NONBLOCK/FNDELAY.
> O_NONBLOCK doesn't necessarily imply "never sleep", it implies "don't
> sleep waiting for an event/long time". So where the mutex is just
> serializing access to hardware that will be very brief it is fine not to
> check O_NONBLOCK/FNDELAY.
Thank you Alan for answering ! One more question I hope you don't mind...
I'm not very confident with all these POSIX definitions. Do you have any
pointers that I should know to get more familiar with them ?
Thanks
Francis
On Tuesday 01 August 2006 14:09, moreau francis wrote:
> Hi
>
> I developped a HW RNG for a custom board and several
> other drivers are using it through a special entry I made.
> I was planning to move the code in order to use the generic
> the RNG layer but I encounter an issue.
>
> Currently it seems not possible for a driver to use HW RNG,
> because there's no entry point for that. Is that something
> deliberate ?
>
Never ever do that. Never use the data from a hardware RNG
directly. There is intentionally no interface to do so.
If you need random data in some driver, use the functions
in random.h to get random data.
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.
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.
> Another question about the implementation. If O_NONBLOCK
> flag is passed when opening /dev/hw_random, how does the
> read method ensure that the caller won't sleep since it calls
> mutex_lock_interruptible() function unconditiannaly ? I must
> miss something but don't know what...
I second Alan's answer here. ;)
--
Greetings Michael.
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.
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.
thanks
Francis
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.
Michael Buesch wrote:
> 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.
Yes, this is the reason why we pass it through userspace...
Jeff
Michael Buesch wrote:
> 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 what I'm currently doing. I was just thinking to use the
new HW-RNG layer and drop common code...
> 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.
>
yes I would like to do that but there is a problem: I have no
access to "rng_mutex" to synchronise hw accesses and I'm
wondering if there's any issue to use a mutex in driver init
code.
>
> 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)?
>
simply because in this embedded system, there's no module support.
thanks
Francis
On Tuesday 08 August 2006 17:39, moreau francis wrote:
> Michael Buesch wrote:
> > 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 what I'm currently doing. I was just thinking to use the
> new HW-RNG layer and drop common code...
>
> > 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.
> >
>
> yes I would like to do that but there is a problem: I have no
> access to "rng_mutex" to synchronise hw accesses and I'm
> wondering if there's any issue to use a mutex in driver init
> code.
Use your own mutex or spinlock in the data_read callback
and use that to serialize accesses to the hardware.
--
Greetings Michael.
Michael Buesch wrote:
> On Tuesday 08 August 2006 17:39, moreau francis wrote:
>> Michael Buesch wrote:
>>> 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 what I'm currently doing. I was just thinking to use the
>> new HW-RNG layer and drop common code...
>>
>>> 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.
>>>
>> yes I would like to do that but there is a problem: I have no
>> access to "rng_mutex" to synchronise hw accesses and I'm
>> wondering if there's any issue to use a mutex in driver init
>> code.
>
> Use your own mutex or spinlock in the data_read callback
> and use that to serialize accesses to the hardware.
>
I think I miss something there but I need to lock this whole
sequence when reading a random data:
lock(hwrng);
rng_data_present();
rng_data_read();
unlock(hwrng);
not only data_read callback. To do that I can only use "rng_mutex",
no ?
thanks
Francis